On 18 March 2017 at 11:51, Marc Mutz <[email protected]> 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.
Ah, so there are correctness problems in addition to performance problems. >> 2) What do we plan to do about those problems? > > Kill QList in Qt 6. How much valid code will that break? How many bugs does that avoid? > 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. As a technical point, reminding me of how std::hash is 'poisoned', and why std::experimental::fundamentals_v2::nonesuch exists, you might want to also prevent default construction, copy/move construction and copy/move assignment. Otherwise an innocent user might create an object of such a type, pass it into a generic function and get a fairly unwelcoming error deep in an instantiation chain. > 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 Urgh. I can't say I'm a fan of functions that vary their return type based on the characteristics of a template parameter. Nor am I a big fan of "auto everywhere". But both might be a necessary evil to provide a migration path that avoids code breakage. > 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. In other words, introduce generic code where there wasn't generic code before - users writing non-generic code calling non-templates that return QLists will need to use deduction or a metaprogramming tool. > 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). It seems that (4) is perfectly safe, whereas (2) and (3) are breaking changes; to what extent, I would like to know. > 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. This certainly seems feasible, but the migration and the extent of it its interesting. There's a fair bunch of QList-using code out there, afaik. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
