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

Andrei Golubev andrei.golubev at qt.io
Wed Sep 9 10:55:45 CEST 2020


Hello,

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.

*- except when detach is necessary or shrinking happens

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.

Feel free to share your opinion or ask questions.

--
Best Regards,
Andrei

________________________________
From: Development <development-bounces at qt-project.org> on behalf of Иван Комиссаров <abbapoh at gmail.com>
Sent: Thursday, September 3, 2020 2:34 PM
To: Jaroslaw Kobus <Jaroslaw.Kobus at qt.io>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray

In the awful world of the standard library we call vector.shrink_to_fit() to ensure that.
Note that while you have your «please free the memory» use-case someone might have the «please do not free memory, I still need it» use-case.

Ivan

3 сент. 2020 г., в 09:40, Jaroslaw Kobus <Jaroslaw.Kobus at qt.io<mailto:Jaroslaw.Kobus at qt.io>> написал(а):

________________________________________
From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> on behalf of Giuseppe D'Angelo via Development <development at qt-project.org<mailto:development at qt-project.org>>
Sent: Wednesday, September 2, 2020 9:37 PM
To: Andrei Golubev; development at qt-project.org<mailto:development at qt-project.org>; Ville Voutilainen
Subject: Re: [Development] Important recent changes in  QList/QString/QByteArray

On 02/09/2020 21:18, Andrei Golubev wrote:
Also not sure whether it is an implementation detail or the behavior
that should always be anticipated.

People build performance sensitive code assuming the cost of certain
operations -- like, assuming that erasing elements from a vector never
reallocates it; and that the only operation that sheds capacity is
squeeze(), everything else (incl. clear(), incl. resize(0)) keeps the
capacity (*). We should stop backstabbing them...

People sometimes care about memory consumption, too. If user's object
contains a vector consisting of exactly one element, he may be surprised
that it still consumes a place for one million elements, just because one
minute ago he removed 999.999 items. If he is creating hundreds
of such objects sequentially, his app may not run at all (however, will perform very well).

Jarek
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200909/9cb5d2e0/attachment.html>


More information about the Development mailing list