22.05.2019, 19:38, "Philippe" <philw...@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 > ???? ?????????? <abba...@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.kn...@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@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.dang...@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@qt-project.org >> https://lists.qt-project.org/listinfo/development >> >> _______________________________________________ >> 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 -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
