On 26/10/2017 20:10, Thorsten Ottosen via Boost wrote:
I'm just rereading all the messages when I came to this one.
That definition seems to satisfy:
A. size() == capacity() implies any insertion /can/ cause reallocation.
B. if( size() + new_elements > capacity ), then reserve() style does not lead to any invalidation in subsequent push_back (addressing Joaquin's concern).
Ion was using the definition "any insertion /will/ cause reallocation.
This is all very subtle since it depends on the definition of reserve() too.
But I think it's the best definition we have seen.
Yes, not only that. These days I was thinking about a modified capacity() definition. If size() == capacity() an insertion can provoke more than optimal data movement (iterator invalidation) and (optionally) reallocation. That could be implemented if capacity() is defined as: max(size(), min(back_capacity(), front_capacity()); If an insertion is done in the side that has free capacity, no data movement and memory allocation is done, but for the user is similar to a in-place buffer expansion. Capacity has grown to accommodate the insertion without moving anything more that needed. If a user want's to be sure if an insertion in one side will be supported without more than optimal data movement or iterator invalidation, then he/she can check back/front_capacity() against size(). I've haven't thought how reserve() is affected. Best, Ion