[Development] RFC: Containers member functions for algorithm

Marc Mutz marc.mutz at kdab.com
Thu Mar 23 10:36:06 CET 2017

On Thursday 23 March 2017 09:27:53 Eike Ziller wrote:
> I do not think that these belong into the API of the containers though, or
> at least if (some of) this API gets into the containers itself, the
> implementation should just call generic functions. There is no reason why
> the convenience should be restricted to the Qt containers, why
> transforming a QVector should be convenient but not transforming a
> std::vector. Adding functions instead of API to the containers also avoids
> bloating the API of the containers, and makes the convenience completely
> optional.

Exactly. Bring back qSort(Container &), calling std::sort(std::begin(c), 
std::end(c)). But leave the container interface alone.

Everyone probably comes up with these (I posted mine in the QList thread: 

That said, there's a reason why there's no std::sort(Container &). It's 
because you need Concepts to disambiguate the various overloads. Well, that 
and because Eric Niebler doesn't manage to limit the scope of his range 

Anyway, I gave my opinion, incl. technical reasons why using member functions 
for this is a bad idea on Gerrit.

I only want to add two things I did not mention there:

First, that one of the usual reasons given for preferring member functions 
over free functions, discoverability, is a tool problem, and should be solved 
in the tools. Include free functions in the .-completion and it no longer 
matters whether a function is a member or a free function. There're proposals 
floating around for years to make o.f() fall back to f(o) for std C++. Ville 
can probably say more about the status of these. This is a problem that can be 
solved now in QtCreator and doesn't require adding more API mistakes.

Second, that member functions always get their *this argument passed by 
reference. A free function can take the argument by value instead. It probably 
doesn't matter much for inline methods. But Chandler has used this example in 
his compiler talks as an example where a seemingly innocuous change (free to 
member function) can make the compiler's job much harder, due to the 
involvement of memory.


Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

More information about the Development mailing list