[Development] Use of Standard Library containers in Qt source code

[Olivier Goffart]

On Freitag, 1. Juli 2016 14:56:36 CEST Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
> > Even today: where is QList::push_back(T&&)? Where are our emplacement
> > functions and their try versions? Where are our exception guarantees?)
> 
> We don't care about exceptions, so we won't be adding those.

Ok.

> As for the move-versions, since we can't take move-only types in our
> containers due to the implicit sharing, does it really make a difference if
> we have them or not?

Well, you point out another weakness of our contaners (not supporting move-
only types).
But even then, the push_back(T&&) overload or emplace functions would still 
usefull to avoid an uneeded copy in some cases. (possibly saving memory 
alocations)

[...]
> > Which again seems like a sensible thing to do in general, unless there
> > are documented cases in which Qt containers significantly outperform STL
> > ones (apart from implicit sharing).
> 
> I would prefer the opposite: use non-Qt only if that is better than the Qt
> equivalent. If you can't prove it or if it's too small, it's not worth the
> difference in readability that it creates.

I think you have an unjustified bias against the STL.
With the exception of "empty", you are overestimating the readability problem 
it pauses.

You also write in another email on this thread:
> You will always see me write a for-loop to fill something rather than use
> std::fill.

And I think you are making a mistake.

Consider:

a)
 std::fill(vec.begin(), vec.end(), computeBackgroundColor());

b)
 for(int i = 0; i < vec.size(); i++)
   vec[i] = computeBackgroundColor();

c)
 auto backgroundColor = computeBackgroundColor();
 for (auto it = vec.begin(); it != vec.end(); ++it)
   *it = backgroundColor;


Personally I find that a. is more readable, as it is objectively more concise 
and cearly express the intent.  b. has some overhead.
Conciseness is important as it reduce the likelyhood of mistake. Also more 
code means more time to read it.

It is true that a lot is a matter of taste, but I totaly buy the reasoning 
behind the "no raw loop".

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org