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-09-28 17:33:09

Den 28-09-2017 kl. 15:02 skrev Joaquin M López Muñoz via Boost:
> 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.

Is that not optimized away?

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

Sure, but is that really a problem? The same can happen with two vector 
instances that have different capacity.

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

Who writes code like that? :-)

Let me try to understand: your problem is that a generic algorithm may 
exhibit a different allocation sequence depending on what type that it 
is given? And you are OK with that happening for the same type?

>> [...]
>>
>>> 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.

You are right, there seems to be missing some postconditions. Also for 
push_front/push_back.

-Thorsten