> A more subtle issue concerns the users of QVector. Wait what? The switch to Qt6 was supposed to become a painless process yet you're introducing important and hard to notice in real code changes that can result in undefined behaviour? What? WHAT?!
On Tue, Sep 1, 2020 at 6:58 PM Giuseppe D'Angelo via Development < [email protected]> wrote: > Hi, > > Thanks for the heads up! > > Il 31/08/20 13:50, Andrei Golubev ha scritto: > > The invalidation existed before for cases when a container could detach > > (due to copy-on-write) or reallocate (due to growing or squeezing). > > This sounds incorrect? Which invalidation did happen due to COW? > > > Now > > this is also true for non-detaching, non-reallocating modifying > operations. > > So, now, formally, std::sort(v.begin(), v.end()) risks undefined > behavior? E.g. begin() returns the begin iterator without touching > anything, but end() decides to invalidate all the iterators. > > Yes, I assume that in practice begin() would already invalidate, and > end() wouldn't, so it would work, but I'm asking what's formal model > now. Is there a way to know that the next non-const call is going to > invalidate everything? > > > Side question, does anyone see a problem with begin() / data() / etc. no > longer be noexcept O(1) operations? > > > Thanks, > > -- > Giuseppe D'Angelo | [email protected] | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
