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

[Andrei Golubev]

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