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: 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:
>> REVIEW FOR DEVECTOR
>
>> 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.back_free_capacity()==2:

 Â  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, 
back_free_capacity()==0

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.

Best

Joaquín M López Muñoz