> 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 <[email protected]> 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 <[email protected]> > *Sent:* Wednesday, September 2, 2020 3:28 PM > *To:* Andrei Golubev <[email protected]> > *Cc:* Giuseppe D'Angelo <[email protected]>; > [email protected] <[email protected]>; Ville > Voutilainen <[email protected]> > *Subject:* Re: [Development] Important recent changes in > QList/QString/QByteArray > > On Wed, 2 Sep 2020 at 15:19, Andrei Golubev <[email protected]> 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 > [email protected] > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
