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


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