[Development] QList

[Marc Mutz]

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