Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Ion GaztaÃ±aga (igaztanaga_at_[hidden])
Date: 2017-10-27 12:47:38
On 26/10/2017 20:10, Thorsten Ottosen via Boost wrote:
> I'm just rereading all the messages when I came to this one.
> That definition seems to satisfy:
> A. size() == capacity() implies any insertion /can/ cause reallocation.
> B. if( size() + new_elements > capacity ), then reserve() style does not
> Â Â lead to any invalidation in subsequent push_back (addressing
> Joaquin's concern).
> Ion was using the definition "any insertion /will/ cause reallocation.
> This is all very subtle since it depends on the definition of reserve()
> But I think it's the best definition we have seen.
Yes, not only that. These days I was thinking about a modified
If size() == capacity() an insertion can provoke more than optimal data
movement (iterator invalidation) and (optionally) reallocation. That
could be implemented if capacity() is defined as:
max(size(), min(back_capacity(), front_capacity());
If an insertion is done in the side that has free capacity, no data
movement and memory allocation is done, but for the user is similar to a
in-place buffer expansion. Capacity has grown to accommodate the
insertion without moving anything more that needed.
If a user want's to be sure if an insertion in one side will be
supported without more than optimal data movement or iterator
invalidation, then he/she can check back/front_capacity() against size().
I've haven't thought how reserve() is affected.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk