[Development] Important recent changes in QList/QString/QByteArray
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Wed Sep 9 11:17:52 CEST 2020
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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200909/2cb2c54b/attachment-0001.bin>
More information about the Development
mailing list