Boost logo

Boost :

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at