Hi,
Been trying to implement this, and of course there are some complications :)
> On 22 May 2019, at 21:36, Mutz, Marc via Development
> <development@qt-project.org> wrote:
>
> Hi Lars,
>
> On 2019-05-22 15:49, Lars Knoll wrote:
>> Let’s conclude the topic of QList. I do see the concern about silent
>> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>> 1. Rename QList to QArrayList and make QList an alias to QArrayList
>
> Agreed.
>
>> 2. Move QStringList and QByteArrayList over to inherit from QVector
>> (that should be source compatible)
>
> Agreed.
>
>> 3. Rename QStringList to QStringVector (keep QStringList as a
>> compatibility name), same for QBAList
>
> Not necessary, in my mind (List is a general concept, think ListView, not
> just a linked list). But not strongly opposed b/c/o the compat typedef.
>
>> 4. Use QVector to implement QList<Foo>, if sizeof(Foo) <=
>> sizeof(quint64) and Foo is movable. I’m intentionally not using
>> sizeof(void *) here, as types with sizes between 4 and 8 bytes would
>> not have stable references in cross platform code, so I do not believe
>> lots of code would assume that (or it would have broken on 64 bit).
>
> Agreed. This matches what QList currently does, minus the padding, which is
> good.
I tried this, and the problem here is that this requires T to be fully declared
at the time you instantiate QList<T>. This is a source incompatibility for
class declarations such as
class MyClass {
QList<MyForwardDeclaredType> list;
};
This worked in Qt 5, but wouldn’t work here anymore as I can’t select the
implementation of QList for a forward declared class.
At the same time, I’m not really willing to compromise on this point, as I
really want to have a zero copy conversion between QList and QVector for small
movable types (the most common case).
>
>> 5. Add a compile time switch that allows mapping QList completely to
>> QVector or to a compatibility mode where QLists of large/non movable
>> types are mapped to QArrayList
>
> I agree with the compile-time switch, provided a) it defaults to QList as per
> (4), otherwise QArrayList (iow: Q5List behaviour minus the padding) and b)
> the switch goes away before Qt 6.0.0 is released. I see this as a way to help
> wip/qt6 get to all-vector APIs without breaking the world. So CI on wip/qt6
> would flip the switch to all-vector to see what breaks, at the same time the
> default would be to keep Q5List-mod-padding to not destroy git-bisect-ability
> across wip/qt6 commits.
>
>> 6. For now we don’t yet want to explicitly change all our API that
>> uses QList to use QVector (as that would make merging from dev a pain,
>> let’s do that later this year). But to test that everything we have
>> works with QVector, we’ll set the compile switch to default to mapping
>> to QVector.
>
> This is the only reason why I'd accept a compile switch, and that's why I'd
> very much like it to be gone by Qt 6, and why I think it shouldn't default to
> QVector. The CI can test with that (and with the old behaviour), individual
> developers may choose what they want, too, but the default for the wider
> audience tracking development should be backwards-compat. We don't want Qt to
> break for everyone because a few people are trying to eradicate the last
> reference-stability users.
I don’t see why you’d want to remove the switch for Qt 6. It would be a porting
help for application developers.
>
>> 7. Make the implementation of QArrayList fully inline and deprecate the
>> class.
>
> I don't think it needs to be fully inline, but I'm not opposed. If it's
> called QArrayList and always heap-allocates, incl. for <int>, I'm also not
> sure it needs deprecating.
Let’s see. I agree that we should in this case consider it always using
IndirectLayout to make it consistent and easy to understand.
Cheers,
Lars
>
>> Let me know if there are any major concerns with this plan. It should
>> give us a good compromise, where we can move all of Qt over to QVector
>> and test things early, as well as providing a compatibility mode for
>> our users (slower but won’t silently break).
>
> To summarize: I agree with the plan, provided QList in Qt 6.0.0
> unconditionally behaves like Q5List-mod-padding (upping the trigger from
> sizeof(void*) to 8 is ok, too), QList as as name is deprecated and as any
> type has implicit deprecated conversions from/to QVector.
>
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
