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-10 08:08:27

Den 10-10-2017 kl. 00:12 skrev Ion Gaztañaga via Boost:
> On 09/10/2017 10:30, Thorsten Ottosen via Boost wrote:
>> What if we did this:
>>
>> capacity() -> alias for back_capacity
>> back_capacity() -> return size() + back_free_capacity()
>> front_capacity() -> return size() + front_free_capacity()
>>
>> ?
> 
> I think it's very confusing. If we move elements while inserting on one 
> end and the free capacity of that end is zero, then capacity() has 
> sense, it's the limit where memory will be reallocated.

Let's not mix moving in push_back/push_front with reallocation (*).

The above definition solve exactly what you and Joaquin saw as a problem 
while at the same time /generalizing/ the vector behavior for both ends.

If we have - as free space and x as elements, then

  -----xxxxxxxxxxxxx---------

  ^^^^^ front free capacity
  ^^^^^^^^^^^^^^^^^^ front capacity
       ^^^^^^^^^^^^^ size
                    ^^^^^^^^^ back free capacity
       ^^^^^^^^^^^^^^^^^^^^^^ back capacity (a.k.a capacity)

The limit where new memory is acquired for insert can be found easily 
enough.

Basically we can't both generalize vector behavior and get the segment 
size in one function. So pick one or none. Two of them allow generic 
code to compile.

kind regards

Thorsten

(*) If push_back/push_front steals memory from the other end, we should 
be cautious about when this is done (potentially high constant factors 
as mentioned in the analysis you found). But it is more than that: it 
may mean that push_back/push_front cannot give the strong 
exception-safety guarantee. Are you really given that away for 
Boost.Container's vector? (I hope not).