[Development] QList

[Konstantin Tokarev]

25.05.2017, 02:19, "Ville Voutilainen" <ville.voutilainen at gmail.com>:
> On 24 May 2017 at 22:25, Marc Mutz <marc.mutz at kdab.com> wrote:
>>  On 2017-05-24 15:12, Konstantin Tokarev wrote:
>>>  24.05.2017, 15:49, "NIkolai Marchenko" <enmarantispam at 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

> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin