Hi,
Op 29/05/2017 om 14:53 schreef Jason H: >> Sent: Thursday, May 25, 2017 at 7:03 PM >> From: "André Somers" <[email protected]> >> To: "Christoph Feck" <[email protected]> >> Cc: [email protected] >> Subject: Re: [Development] QList >> >> Hi, >> >> On 25 May 2017, at 18:40, Christoph Feck <[email protected]> wrote: >> >>>> On 25.05.2017 13:53, André Somers wrote: >>>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >>>>> 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. >>> If you only return a view to the container, then if the container is >>> modified, the return value is no longer valid. Returning a full container >>> (referenced, with copy-on-write semantics) will not have this problem. >> Sure, but do you always or even most of the time need that feature? If not, >> why always pay for it? And it would be easy to turn it into a container when >> needed, but then you can choose the most appropriate for your task instead >> of always getting a QList (now) or a QVector (Qt6?) > > > > I wonder how gsl::span plays into this. I just learned about span, quick > seems to be wet we need here? > Not at all, I think. gsl::span is "a non-owning range of contiguous memory" according to https://www.quora.com/What-is-the-span-T-in-the-CppCoreGuidelines. As QList does not obey that definition, it would rule out being a view into QList (or its successor with the same semantics) already. André _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
