[Development] QList

[Philippe]

>> For me, the performance issue is pretty strong 

QVector is not always the best solution here.
With QList, insertion and sorting will be faster for containers of large
objects, as there is less memory to move around.

QList is not to put to the trash.

Philippe


On Sat, 18 Mar 2017 10:51:06 +0100
Marc Mutz <marc.mutz at kdab.com> wrote:

> On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote:
> > There's been a fair amount of talk about QList's future, so I'm curious:
> > 
> > 1) What are the problems with QList?
> 
> See Konstantin's reply. For me, the performance issue is pretty strong 
> already, but that stability of references into QLists may depend on such 
> subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been 
> called for the type is also a big correctness issue.
> 
> > 2) What do we plan to do about those problems?
> 
> Kill QList in Qt 6.
> 
> > 3) How do we expect to migrate code that uses it?
> 
> Possibly provide a QArrayList that _always_ uses the heap, and thus _always_ 
> provides stability of references. There's some code that actually depends on 
> stability of references (QToolBox, e.g.).
> 
> Try to minimize use in new code. That hasn't worked out as planned. Look at 
> the dates of my two contributions Konstantin linked to, then look at the API 
> reviews for 5.9. It's almost guarateed that Q_DECLARE_TYPEINFO (or the similar 
> Q_DECLARE_SHARED) have been "forgotten". Review regularly fails for such 
> things.
> 
> This experience, over several years, has thaught me that we need a technical 
> solution. And so we started to specialize QList<QNewType> as an empty class. 
> So far, this is the only workable solution I have found, and believe me, I am 
> very determined.
> 
> I think we should do this for all new (non-polymorphic) classes.
> 
> And since we now depend on enough C++11, replacing QList with QVector in 
> generic code is trivial: either use auto, or when you can't, use 
> QListOrVector, introduced here: https://codereview.qt-project.org/188858
> 
> So, here's my proposal for a QList exit strategy:
> 
> In Qt 5:
> 
> 1. Replace QList in generic code by QListOrVector, tell users to hold QLists
>    they get from Qt API only in type-deduced variables.
> 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I
>    don't think toSet() should be either on QList nor QVector, because it
>    creates nonsense like qHash(QItemSelectionRange) (please, please, look it
>    up :)
> 3. Disable QList for all new QFoo value types (by specializing QList<QFoo> as
>    an empty class).
> 4. Provide QArrayList for code that needs stability of references (stability
>    statically checked in Qt 5, enforced in Qt 6).
> 
> In Qt 6:
> 
> 5. Replace all QList uses left with ... what ? QVector? std::vector?
>    -> separate discussion
> 6. Kill QList or keep it as a deprecated class.
> 
> Thanks,
> Marc
> 
> > Pardons all around for not being up to date if there's some material
> > on the points
> > above; feel free to point me to such material.
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development