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