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

[Andrei Golubev]

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.

--
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 4:47 PM
To: Ville Voutilainen <ville.voutilainen at gmail.com>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray

Il 02/09/20 10:04, Ville Voutilainen ha scritto:
> Interesting. I'm curious what sort of repacking happens on erase, and why
> it wasn't done in such a way that e.g. QVector is 4 pointers instead
> of 3, so that
> 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.

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?

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/406dad6c/attachment.html>