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

[NIkolai Marchenko]

>   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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200902/524de497/attachment-0001.html>