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


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