Boost logo

Boost :

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-09-28 13:02:00

El 27/09/2017 a las 21:27, Thorsten Ottosen via Boost escribió:
> Den 26-09-2017 kl. 23:43 skrev Joaquin M López Muñoz via Boost:
>> and violates the "don't pay for what you don't use" principle. I'd
>> remove it.
> How does it violate that?

All the _storage handling is done even if there's the small buffer is 0.

>> 7. Modulo the points discussed above, the interface of devector
>> follows closely that
>> of std::vector (with the obvious additions, e.g.
>> [push|pop_emplace]_front), which is
>> very good. The only interface decisions I'm not fully convinced about
>> is capacity/
>> resize/reserve/shrink_to_fit without "front" or "back" qualification:
> What about generic code that can be used with either a vector or
> devector?

Problem is: suppose d.size()==5,
d.capacity()==10,d.back_free_capacity()==2; doing

 Â  for(int i=0;i<5;++i)d.push_back(i)

will reallocate, unlike std::vector.

> [...]
>>    - front_free_capacity/back_free_capacity could be more aptly named
>>    front_capacity/back_capacity.
> But unlike capacity() in vector, these actually tells you how many
> push_back/push_front
> you can do without reallocation. There is no definition of "back
> capacity" because there
> is no "middle".

You're right, my bad. the _free_ infix is very adequate.

>>    - reserve as an alias to reserve_back has usability  problems as
>> discussed with capacity.
> Again, what about generic code?

Similar consistency problem with std::vector. d.size()==5, d.capacity()==10,

 Â  d.reserve(d.capacity())

reallocates, whereas it is a no-op for std::vector.

>>    I'd remove them.
>>    - For symmetry, shrink_to_fit could be complemented with
>> [front|back]_shrink_to_fit
> Is back_shrink_to_fit then an alias for shink_to_fit or does it actually
> consider both ends?

The semantics that seems to me the cleanest is

 Â  * shrink_to_fit --> front_free_capacity()==0, back_free_capacity()==0
 Â  * front_shrink_to_fit --> front_free_capacity()==0,
back_free_capacity() untouched
 Â  * back_shrink_to_fit --> front_free_capacity() untouched,

Strictly speaking, standard says shrink_to_fit is an *indication*, so
implement all
three as no-ops would comply :-)

> [...]
>> 3. Tests look good.
>> 4. Postconditions on front and back capacity are not documented.
> You mean front_free_capacity etc? What condition did you have in mind?
> The funcions are const.

Sorry, I meant there is no indication of what happens to
[front|back]_free_capacity after
insertions and erasures.


Joaquín M López Muñoz

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