[Development] QList for Qt 6
Konstantin Tokarev
annulen at yandex.ru
Wed May 22 18:41:42 CEST 2019
22.05.2019, 19:38, "Philippe" <philwave at gmail.com>:
>> People tend to use QList as a deque because of the fast prepend/take first
>
> Simply, QArrayList should not be deprecated.
> It is also useful to store large objects that needs to be sorted.
In the latter QList can be replaced with std::vector<std::unique_ptr<T>> or QVector<std::unique_ptr<T>>
>
> Philippe
>
> On Wed, 22 May 2019 18:25:18 +0200
> ???? ?????????? <abbapoh at gmail.com> wrote:
>
>> 4. Use QVector to implement QList<Foo>, if sizeof(Foo) <= sizeof(quint64) and Foo is movable
>>
>> What about fast prepend in that case? People tend to use QList as a deque because of the fast prepend/take first
>>
>> ???? ??????????
>>
>> 22 ??? 2019 ?., ? 15:49, Lars Knoll <lars.knoll at qt.io> ???????(?):
>>
>> Lets conclude the topic of QList. I do see the concern about silent source breakages. Heres what well (Ill) do then for Qt 6:
>>
>> 1. Rename QList to QArrayList and make QList an alias to QArrayList
>> 2. Move QStringList and QByteArrayList over to inherit from QVector (that should be source compatible)
>> 3. Rename QStringList to QStringVector (keep QStringList as a compatibility name), same for QBAList
>> 4. Use QVector to implement QList<Foo>, if sizeof(Foo) <= sizeof(quint64) and Foo is movable. Im 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).
>> 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
>> 6. For now we dont yet want to explicitly change all our API that uses QList to use QVector (as that would make merging from dev a pain, lets do that later this year). But to test that everything we have works with QVector, well set the compile switch to default to mapping to QVector.
>> 7. Make the implementation of QArrayList fully inline and deprecate the class.
>>
>> 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 wont silently break).
>>
>> Cheers,
>> Lars
>>
>> On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
>>
>> Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
>> That's a hard one. Especially since very few could keep in their brain a list of the sizes of each and every one class from Qt. It also differs depending on architecture.
>>
>> I know. That's my point: we can't just break this level of source compatibility.
>>
>> Thanks,
>>
>> --
>> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
>> KDAB (France) S.A.S., a KDAB Group company
>> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Regards,
Konstantin
More information about the Development
mailing list