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-30 18:27:35

Den 27-10-2017 kl. 14:47 skrev Ion Gaztañaga via Boost:
> On 26/10/2017 20:10, Thorsten Ottosen via Boost wrote:

>> But I think it's the best definition we have seen.
> 
> Yes, not only that. These days I was thinking about a modified 
> capacity() definition.
> 
> If size() == capacity() an insertion can provoke more than optimal data 
> movement (iterator invalidation) and (optionally) reallocation. That 
> could be implemented if capacity() is defined as:
> 
> max(size(), min(back_capacity(), front_capacity());

Is this not just equivalent to

   min(back_capacity(), front_capacity())

given that back/front_capacity >= size()?

> If an insertion is done in the side that has free capacity, no data 
> movement and memory allocation is done, but for the user is similar to a 
> in-place buffer expansion. Capacity has grown to accommodate the 
> insertion without moving anything more that needed.
> 
> If a user want's to be sure if an insertion in one side will be 
> supported without more than optimal data movement or iterator 
> invalidation, then he/she can check back/front_capacity() against size().

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.

And given that we do provide means for exact queries (this code will 
reallocate unless you call reserve_xxx), I don't know if it makes any 
sense to use time on capacity.

My only point was: Nevin's definition would solve Joaquin's concern if 
reserve() was an alias for reserve_back(), but since we may not want to 
do that (e.g., depending on policy, reserve() could allocate space in 
both ends), I think the best option is to drop capacity() for devector
and dream about a standard that had used the names 
back_capacity()/reserve_back()/resize_back() for what it now calls 
capacity()/reserve()/resize().

kind regards

Thorsten