On 24 May 2017 at 22:25, Marc Mutz <[email protected]> wrote: > On 2017-05-24 15:12, Konstantin Tokarev wrote: >> >> 24.05.2017, 15:49, "NIkolai Marchenko" <[email protected]>: >>> >>> A semi-sane idea that I think no one has suggested yet: >>> >>> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a >>> contructor from this type? >>> After all making existing code slightly _slower_ because of the wrapping >>> overhead is way less problematic than breaking it outright. >>> It will nudge the users of QLists that need to be fast to switch but will >>> leave users of "default no brainer container" happy as they likely wouldn't >>> even notice. >> >> >> If existing Qt APIs switch from QList to QVector in Qt 6, such change >> will make it hard to support both Qt 5 and Qt 6 in the same code base. > > > Which is why I suggested to make QList a type alias for QVector or > QArrayList, depending on some yet-to-be-determined criteria. Obvious > candidates algorithms are:
I think we need to take a serious step backwards here. I, for various reasons, got the impression that a major problem at hand is that when a user (NOT in any template code, necessarily) uses QList<Foo>, that user doesn't know the consequences. Mostly because depending on the characteristics of Foo, the user doesn't know what the performance characteristics and semantics of QList<Foo> are, because QList might or might not use (in)direct storage. Perhaps I completely fail to understand the problem space. I (think I) have read Marc's writings on the subject matter, but chances are that the crux of the matter is still escaping me. How does it help anyone to create a new alias that still results in a concrete type the semantics of which still depend on the element type? _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
