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
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.