annulen at yandex.ru
Thu May 25 12:38:37 CEST 2017
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
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
More information about the Development