On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote: > On 29 March 2017 at 11:29, Marc Mutz <[email protected]> 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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
