Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: > > 25.05.2017, 02:19, "Ville Voutilainen" <ville.voutilai...@gmail.com>: >> On 24 May 2017 at 22:25, Marc Mutz <marc.m...@kdab.com> wrote: >>> On 2017-05-24 15:12, Konstantin Tokarev wrote: >>>> 24.05.2017, 15:49, "NIkolai Marchenko" <enmarantis...@gmail.com>: >>>>> 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 > I think you bring up a good point there. Would not the best way out be to fix exactly this problem? If these functions would not return a container, but some type of view into such a container, that would leave users free to choose the type of container they need for their job instead of being forced into the direction Qt choose for its API. A view might take the form of a pair of iterators, a range, or perhaps even some specialized class that basicaly wraps a pair or iterators and that provides convenience functions to/from the Qt containers.
André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development