Boost logo

Boost :

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).


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk