[Development] QList

[Mark Gaiser]

On Sat, Mar 18, 2017 at 10:51 AM, 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.
>
>> 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?