Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

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() 
> too.
> 
> But I think it's the best definition we have seen.

Yes, not only that. These days I was thinking about a modified 
capacity() definition.

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.

Best,

Ion