Hi Nevin,
On Thu, Oct 12, 2017 at 12:17 PM, Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
On 12/10/2017 10:37, Thorsten Ottosen via Boost wrote:
That means your design where capacity is the the full buffer length can
satisfy both situations. So I agree with you. But it also calls into question the need for anything else than capacity (i.e., there seem to be vanishingly little use for back_capacity/front_capacity and they probably confuse more than they help).
I agree. If capacity is the full buffer length, only back/front_capacity make sense.
Normally, my check against capacity() is usually about iterators, pointers and/or references possibly being invalidated more than knowing that an actual allocation will take place.
Have we considered capacity() == min(front_capacity(), back_capacity())?
Just a thought,
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. kind regards Thorsten