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
> 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.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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk