Den 11-10-2017 kl. 21:00 skrev Ion Gaztañaga via Boost:
On 11/10/2017 13:20, Thorsten Ottosen via Boost wrote:
why? If the vector is full, capacity() == size(). If the devector's right hand size is full, size() == back_capacity().
But if capacity() is an alias for back_capacity() and size() == capacity(), an insertion in the middle would not trigger a reallocation. capacity() > size() means to me "is there room for a new insertion without reallocation"?
capacity == size means that any insertion will lead to reallocation.
That's the alternative, but that is the one that breaks generic code, isn't it?.
Which generic code? I think it's the opposite.
We started with code like (*) if( container.capacity() > container.size() + new_elements ) container.reserve( container.size() + new_elements ); ... for( ... ) container.push_back(...); and we found that this would sometimes not reallocate for devector. So I proposed a design that did. But now ...
For any container with reserve/capacity (vector, string, flat_map, circular_buffer, poly_collection, etc.) if capacity() == size() that means a reallocation will happen for *any* insertion, not just push_back. If you want guarantees for back insertion only, then back_capacity() should give you the answer. Just my 2 cents.
... we broke capacity() == size() means that any insertion will reallocate. What I was trying to convey is that there is no definition of capacity/back_capacity etc that can simultaneously satisfy both. I think the guiding principle should be to support idiomatic code. (*) is not idiomatic: there is absolutely no reason to guard a call to reserve when you can just write: container.reserve( container.size() + new_elements ); 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 do think reserve is harder to use than it should be. I would have preferred it was called container.anticipate_back( new_elements ); which works regardless of the size of the container. kind regards Thorsten