> 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.voutilai...@gmail.com> Sent: Wednesday, September 2, 2020 3:28 PM To: Andrei Golubev <andrei.golu...@qt.io> Cc: Giuseppe D'Angelo <giuseppe.dang...@kdab.com>; development@qt-project.org <development@qt-project.org>; Ville Voutilainen <ville.voutilai...@qt.io> Subject: Re: [Development] Important recent changes in QList/QString/QByteArray On Wed, 2 Sep 2020 at 15:19, Andrei Golubev <andrei.golu...@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@qt-project.org https://lists.qt-project.org/listinfo/development