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

[Ville Voutilainen]

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.