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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- 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
