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