Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk