On Sat, Mar 18, 2017 at 10:51 AM, Marc Mutz <marc.m...@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
Hi Marc, I'm fine with replacing QList usages with QVector in codebases i maintain, but even with the latest Qt version, that isn't always possible or convenient. For instance, at this very moment i want a QVector with all keys from a given map (QMap<QDate, QString>) but Qt itself doesn't provide a direct way of doing that. The keys method on the map returns a QList. QList has a "toVector" method which gives me the QVector i want. It works, yes. But it's really indirect. The key kinda has to be unique in a map (and hash) so it would be perfectly fine for it to be a QVector, but it isn't. Is there a technical reason for it or is it just because of Qt's history? _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development