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

[Andrei Golubev]

Even if the capacity has been reserved by the user?
No, in the case of reserved capacity we do not shrink. However, unlikely every call to erase that is to break is covered by a reserve somewhere earlier in the code. Also not sure whether it is an implementation detail or the behavior that should always be anticipated.
> With this setup, one might be tempted to optimize erasure in the first
> half of the container by shifting elements towards the end (rather than
> from the end towards the beginning), as it would be cheaper. I guess
> that's what's happening here?
>
>
> Yes, this is what's happening now. But I am considering switching back to std::vector::erase mode, there's a patch for that already. Let's see how it goes.

After feature freeze? :)
Well, technically there were no explicit guarantees on erase beforehand (also see the shrinking thing), so my suggestion is to not even consider new update (if it is going to happen) as a behavior change in the first place (read as can be done after FF). Once we decide upon it, the plan is to document it => effectively fix the behavior at least until Qt 7.

--
Best Regards,
Andrei

________________________________
From: Development <development-bounces at qt-project.org> on behalf of Giuseppe D'Angelo via Development <development at qt-project.org>
Sent: Wednesday, September 2, 2020 8:21 PM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray

Il 02/09/20 17:38, Andrei Golubev ha scritto:
>
> But yes, good job bringing this up. In Qt 6 code base we also do the
> shrinking in erase. So this already is not aligned with std::vector.

Even if the capacity has been reserved by the user?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200902/7afeefbb/attachment.html>