marc.mutz at kdab.com
Sat Mar 18 10:51:06 CET 2017
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
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
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
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.
> 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
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt, C++ and OpenGL Experts
More information about the Development