[Development] Important recent changes in QList/QString/QByteArray

[Dmitriy Purgin]

By the way, a bit off topic but what happened to the plan to make QVector
the primary container in Qt 6, and why has it been turned the other way
round? The official documentation [1] still refers to Marc's article [2]
that says that QVector should be preferred over QList. As far as I
remember, until recently, for years we were told in this mailing list to
move away from QList and use QVector as default, because QList will be
deprecated/removed in Qt 6 anyway. A quick search reveals [3, 4, 5].

[1] https://doc.qt.io/qt-5/qlist.html
[2] https://marcmutz.wordpress.com/effective-qt/containers/
[3] https://lists.qt-project.org/pipermail/interest/2017-May/027055.html
[4] https://lists.qt-project.org/pipermail/development/2015-July/022283.html
[5] https://lists.qt-project.org/pipermail/development/2019-May/036130.html

Cheers
Dmitriy

On Wed, Sep 2, 2020 at 3:06 PM NIkolai Marchenko <enmarantispam at gmail.com>
wrote:

> >   This is the difference between QList and std::vector.
> You are aliasing QVector into a QList if I understand it correctly. This
> means a major compatibility break in a ton of code. Unless QVector also
> worked like that which I doubt was the case.
>
> On Wed, Sep 2, 2020 at 3:53 PM Andrei Golubev <andrei.golubev at qt.io>
> wrote:
>
>> > Interesting. I'm curious what sort of repacking happens on erase
>> >
>> > The iterators before or after may be invalidated. Exactly which of the
>> two (before or after) is going to happen depends on the position of the
>> to-be-erased range with regards to the position of the full range.
>>
>> I don't quite understand why a vector erase would invalidate vector
>> elements before the erased position.
>>
>> This is the difference between QList and std::vector.
>>
>> > the element storage wouldn't necessarily be at the beginning of the
>> > allocated block;
>> > in that approach, a pop_front would merely bump the begin, and erase
>> > still wouldn't
>> > invalidate anything before the erased position.
>> >
>> > I guess you mean "erase still wouldn't invalidate anything after the
>> erased position".
>>
>> No. I mean "before", not "after". That's how std::vector works. An
>> erase is a shrinking operation
>> that keeps everything before the erased position untouched and
>> left-shifts everything after it. If you
>> want a prepend optimization, you can get it without changing the way
>> erase works and what the
>> invalidation guarantees of erase are, so I'd like to understand what
>> in our implementation strategy
>> necessitates this change to those guarantees.
>>
>> I do not have use cases at hand so cannot really back up my words by
>> evidence. The erase strategy with invalidation either "before" or "after"
>> is the strategy of Qt 5 QList. Similar thing is done with Qt 6 QList
>> (a.k.a. QVector). Indeed, it's not aligned with std::vector::erase().
>>
>> >But this is effectively undefined (or implementation-specific, as you
>> wish) and may change in future if we discover a more performing strategy.
>> Again, any exceptions should be documented. Please do not assume any
>> specific behavior otherwise.
>>
>> This seems like a potentially quite significant compatibility break,
>> that chopping a vector invalidates all references
>> and iterators to parts of the vector that the chopping didn't touch
>> before.
>>
>>
>> --
>> Best Regards,
>> Andrei
>>
>> ------------------------------
>> *From:* Ville Voutilainen <ville.voutilainen at gmail.com>
>> *Sent:* Wednesday, September 2, 2020 3:28 PM
>> *To:* Andrei Golubev <andrei.golubev at qt.io>
>> *Cc:* Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>;
>> development at qt-project.org <development at qt-project.org>; Ville
>> Voutilainen <ville.voutilainen at qt.io>
>> *Subject:* Re: [Development] Important recent changes in
>> QList/QString/QByteArray
>>
>> On Wed, 2 Sep 2020 at 15:19, Andrei Golubev <andrei.golubev at qt.io> wrote:
>> > Ville:
>> >
>> > Interesting. I'm curious what sort of repacking happens on erase
>> >
>> > The iterators before or after may be invalidated. Exactly which of the
>> two (before or after) is going to happen depends on the position of the
>> to-be-erased range with regards to the position of the full range.
>>
>> I don't quite understand why a vector erase would invalidate vector
>> elements before the erased position.
>>
>> > the element storage wouldn't necessarily be at the beginning of the
>> > allocated block;
>> > in that approach, a pop_front would merely bump the begin, and erase
>> > still wouldn't
>> > invalidate anything before the erased position.
>> >
>> > I guess you mean "erase still wouldn't invalidate anything after the
>> erased position".
>>
>> No. I mean "before", not "after". That's how std::vector works. An
>> erase is a shrinking operation
>> that keeps everything before the erased position untouched and
>> left-shifts everything after it. If you
>> want a prepend optimization, you can get it without changing the way
>> erase works and what the
>> invalidation guarantees of erase are, so I'd like to understand what
>> in our implementation strategy
>> necessitates this change to those guarantees.
>>
>> >But this is effectively undefined (or implementation-specific, as you
>> wish) and may change in future if we discover a more performing strategy.
>> Again, any exceptions should be documented. Please do not assume any
>> specific behavior otherwise.
>>
>> This seems like a potentially quite significant compatibility break,
>> that chopping a vector invalidates all references
>> and iterators to parts of the vector that the chopping didn't touch
>> before.
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200902/974b66bb/attachment.html>