ville.voutilainen at gmail.com
Sat Mar 18 11:25:12 CET 2017
On 18 March 2017 at 11:51, Marc Mutz <marc.mutz at 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.
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
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.
More information about the Development