25.05.2017, 02:19, "Ville Voutilainen" <[email protected]>: > 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.
Other problem, that IMO is more serious, is that Qt *requires* user to use QList, by returning or taking it as and argument in various places. That's almost only reason why I use QList in my code[*]. If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with this APIs will break, unless QList will become an alias of QVector. [*] And, fwiw, almost only reason I use QString, but that's off-topic here > 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 -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
