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: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-10-31 01:48:44

On 31/10/2017 07:27, Thorsten Ottosen wrote:
> Sure, we can make new semantics. I think Joaquin's concern was that if 
> we provide both capacity() and reserve(), we better do it 100% 
> compatible with vector.
> 
> In our source code, I found just one mention of capacity(). In the 
> dependencies, less than fourty. And only one involved a comparison with 
> size(). That one in 800-900k lines of code. Other code bases may be 
> different.

At least for vector, I think most codebases make the assumption that 
capacity() will always return a value >= the value passed to reserve(), 
and reason that they're therefore allowed to emplace/push_back() up to 
or equal (reserve-argument minus size()) times without causing further 
allocation or iterator invalidation, and without needing to explicitly 
check the capacity.

It is likely that they would be able to call it even more times (as 
reserve() typically rounds up), but most code would not care about this 
or attempt to do so.

(It's also probably most common that size() == 0 when reserve() is 
called, but not guaranteed.  In cases where it is not, it is then 
probably most common to use reserve(size() + N), where N is the number 
of push_backs you want to make without reallocation/iterator invalidation.)

Unit tests might be more picky.

I don't know whether devector should try to emulate these patterns 
(which might cause over-allocation of the back end) or just require 
people to use reserve_back()/size_back() explicitly instead.