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
Problem is: suppose d.size()==5,
Â 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
> 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,
reallocates, whereas it is a no-op for std::vector.
>> Â Â I'd remove them.
>> Â Â - For symmetry, shrink_to_fit could be complemented with
> 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_shrink_to_fit --> front_free_capacity() untouched,
Strictly speaking, standard says shrink_to_fit is an *indication*, so
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
insertions and erasures.
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk