Should I expect to do a reserve call with a *smaller* value than my current size is before removing elements from a container, in order to set a "target size"? For any standard container, such a reserve is a complete noop because it can't be responded to by shrinking a capacity lower than the size, but with QList it apparently records a preferred size? No. If the value passed to reserve is smaller than capacity, we do not shrink*. For any passed value, we set a specific flag that the capacity is reserved. There is no notion of "target size" and "target capacity" is out of scope of the container (this is something that the user knows about). Instead, having the flag in place, we can decide whether allocation should take place or not. When allocation is not obligatory and the capacity reservation flag is set, we do not reallocate but instead do "something else": in case of erase - just remove elements, in case of prepend - move data around (if necessary). The flag is a mere part of QCC's state.
* let aside the case when QCC is implicitly shared -- Best Regards, Andrei ________________________________ From: Ville Voutilainen <[email protected]> Sent: Thursday, September 10, 2020 3:43 PM To: Andrei Golubev <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Development] Important recent changes in QList/QString/QByteArray On Thu, 10 Sep 2020 at 11:46, Andrei Golubev <[email protected]> wrote: > > That's interesting. So the container remembers what sort of a reserve > request I made on it, and uses > that as the preferred size whenever the element count of the container > changes? > > Yes. Calling reserve typically means that you do not want to have extra > reallocations while updating the container's content (instead you allocate > sufficient space upfront). In case of QList, we make sure there are no > reallocations happening unless absolutely necessary, e.g. appending 1 element > when size == capacity would allocate bigger memory chunk - reservation is a > hint, but not an obligation. Consequently, QList's shrinking erase also does > not shrink when capacity is reserved. Well, yeah - calling reserve before growing a container avoids extra allocations. Calling reserve before removing elements doesn't have such a "typical" effect. Should I expect to do a reserve call with a *smaller* value than my current size is before removing elements from a container, in order to set a "target size"? For any standard container, such a reserve is a complete noop because it can't be responded to by shrinking a capacity lower than the size, but with QList it apparently records a preferred size?
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
