[Development] QList

[Marc Mutz]

On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote:
> On 29 March 2017 at 11:29, Marc Mutz <marc.mutz at kdab.com> wrote:
> > On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote:
> >> Please approve the former, or propose something else.
> > 
> > I actually meant this ^^. Approve or _propose_ something else.
> > 
> > Just to be clear on this: I'm ready to do the work as outlined. But I
> > will most certainly not write a QArrayList-as-a-class-in-Qt-5 that
> > supports QArrayList<int>.
> > 
> > IMO, QArrayList is a marker for the Qt 5->6 transition. It is not a cool
> > new Qt container class. In fact, if I was to decide, I'd deprecate
> > QArrayList on the spot in Qt 6 and remove it in Qt 7.
> > 
> > If you want a QArrayList<int>, write it yourself. Well, or use
> > vector<unique_ptr<int>>.
> 
> Let me take a step back. Do we need a list container that is always
> indirect regardless of
> the element type and uses implicit sharing?
> 
> If I start using QArrayList<indirect_type> today, and it's immediately
> deprecated, what
> should I use instead? vector<unique_ptr<indirect_type>>? That doesn't
> do implicit sharing,

Because it's you who asks: if CoW is so super-important, why did the committee 
drop support for CoWed std::string in C++11?

That brings us straight back to the fundamental question: Why can the C++ 
world at large cope with containers that are not CoW and Qt cannot? The only 
answer I have is "because Qt never tried". And that's the end of it. I have 
pointed to Herb's string measurements from a decade or two ago. I have shown 
that copying a std::vector up to 1K ints is faster than a QVector, when 
hammered by at least two threads. It's not even clear, yet, whether Q6String 
will have SSO. The insistance to ignore two decades of advances in computer 
science combined with a habit to reinforce bad practices just because "we've 
always done so" (I just had to review _another_ pimpl'ed class that contained 
nothing but two enums) by having all the good stuff as an opt-in that no-one 
uses, is slowly getting on my nerves. I can't win this argument, because here, 
too, we're facing post-factual discussions. When you argue that QList is a bad 
default container, people come and say that sorting a QList of 
std::array<1024> is faster than a QVector of the same type, or other corner 
cases like:

> so I can't pass it by value into slots.

Why would you want to? No-one does that. People use cref, like for all large 
types. Qt makes sure that a copy is taken only when needed, ie. when the slot 
is in a different thread from the emitter. That is very rare, and people can 
be expected to pass a shared_ptr<vector> instead in these situations.

Bottomline: don't expect me to support any form of implicit sharing. The 
answer will always be: because you should use explicit sharing.

This is why I see QArrayList as a phase-out vehicle for QList, not as a fancy 
new container.

Thanks,
Marc

-- 
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