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

[Andrei Golubev]

This is another against automatic shrinking; it may invalidate
everything rather than just the erased area. I don't understand the
"detach" part, is it about holding references across a detach, so they
refer to the original container, not the detached one? That's not
different from we always had, isn't it?
You are correct about detach.
Are the new behaviors autotested for all the leaf classes, incl. things
like detaching a reserve()d container? The usual problem is that the
code duplication in QVector/QString/QByteArray gave them completely
different behaviors (there's a number of bug reports open).
Unlikely fully tested. From what I see, there are certain tests for QList's erase (incl. reserve + erase), though there is no behavior validation of what happens with capacity.
QList/QString/QBA certainly have behavior differences now. For instance, shrinking erase is only done for QList (seems to be an extra point against auto-shrinking). Also remember null-termination of QString/QBA and QString/QBA::_empty - this stuff affects things like capacity()/size().
Prepend optimization forced to make behavior more aligned, QBA's modifying functions were updated to use the same "backend" as QList does. QString (and QString-using code) is a bit tougher one, so not fully converted yet. Anyhow, the devil is in the details around the operations on elements (e.g. detach, reserve).
Guessing that by "detaching a reserve()d container" you ask what the detached container knows about prior reservation - detached contained knows that the capacity was reserved. Couldn't find tests for that, however.

--
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 9, 2020 12:17 PM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray

On 09/09/2020 10:55, Andrei Golubev wrote:
> Small update on QList::erase: the iterator invalidation model will be
> aligned with std::vector's erase (in progress of merging the change to
> dev and it got approved already). This means that, when erasing, only
> the iterators that correspond to erased elements and elements after them
> (until end()) will be invalidated*. The corner case is erasing from the
> beginning where formal definition seems to allow right-shifting erasure
> (feel free to prove me wrong) and the only concern I have is when
> someone holds QList::constData()/data() pointer, since this will be
> invalidated in the corner case.

data() is invalidated if one erases begin(), so no problem.

>
> *- except when detach is necessary or shrinking happens

This is another against automatic shrinking; it may invalidate
everything rather than just the erased area. I don't understand the
"detach" part, is it about holding references across a detach, so they
refer to the original container, not the detached one? That's not
different from we always had, isn't it?

> As to whether we should or should not shrink when erasing too many
> elements, there are clearly two opposite opinions (see the "replied to"
> conversation).
> My assumption would be that shrinking in erase has some justification
> (otherwise, why do it in the first place?). Thus, there are already
> Qt-relevant cases that benefit from having smaller memory footprint.
> On the other hand, "please do not free memory, I still need it" use-case
> is also justified. However, chances are that when you really need a
> certain memory to be allocated/preserved, there is a call to
> QList::reserve() prior to insertions/deletions. And since we do not
> shrink in case of reserved memory, users should be safe in this case, in
> general.

Are the new behaviors autotested for all the leaf classes, incl. things
like detaching a reserve()d container? The usual problem is that the
code duplication in QVector/QString/QByteArray gave them completely
different behaviors (there's a number of bug reports open).

--
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/20200909/6a42a891/attachment.html>