Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-10-12 08:37:09

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