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

[NIkolai Marchenko]

>  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 <
development at qt-project.org> 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 | giuseppe.dangelo at kdab.com | 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
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200901/863c448c/attachment-0001.html>