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 <[email protected]> on behalf of Giuseppe D'Angelo via Development <[email protected]> Sent: Wednesday, September 9, 2020 12:17 PM To: [email protected] <[email protected]> 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 | [email protected] | 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 [email protected] https://lists.qt-project.org/listinfo/development
