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: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-10-26 18:10:55

Hi Nevin,

> On Thu, Oct 12, 2017 at 12:17 PM, Ion Gaztañaga via Boost <
> boost_at_[hidden]> wrote:
> 
>> On 12/10/2017 10:37, Thorsten Ottosen via Boost wrote:
>>
>> That means your design where capacity is the the full buffer length can
>>> satisfy both situations. So I agree with you. But it also calls into
>>> question the need for anything else than capacity (i.e., there seem to be
>>> vanishingly little use for back_capacity/front_capacity and they probably
>>> confuse more than they help).
>>>
>>
>> I agree. If capacity is the full buffer length, only back/front_capacity
>> make sense.
>>
> 
> Normally, my check against capacity() is usually about iterators, pointers
> and/or references possibly being invalidated more than knowing that an
> actual allocation will take place.
> 
> Have we considered capacity() == min(front_capacity(), back_capacity())?
> 
> Just a thought,

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.

kind regards

Thorsten