Boost logo

Boost :

Subject: Re: [boost] double_ended - request formal review
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2016-08-23 10:06:25


On 26-07-2016 18:14, Michael Marcin wrote:

> I haven't looked at the code but from your description it seems like
> there is an implicit connection between reserve_front and reserve_back.
>

Rather, it is the opposite: they are independent. Calling one does not
modify the promise of the other.

> I would expect this to be explicit and there to be 3 reserve methods.
>
> reserve_front( size )
> reserve_back( size )
> reserve( front_size, back_size )
>
> And that the implementation only maintain stability until a realloc
> occurs from any source (push/insert/reserve/whatever).

Since devector strives to be close to vector, it has a reserve function
taking one argument which does what vector does (important for generic
code). I guess a two argument version would add a slight convenience,
but not much.

> If a realloc occurs it should be free to reposition the elements in the
> already allocated memory block by rotating them forward or back.
>
> It should also be free to change the available capacity at either end.

Yeah, but the hard question is what is gained by that? What would a
sound policy look like? There is the policy parameter which could do
more things, but we need a really sound policy for moving things around
implictly. I suspect that it will create confusing and lead to few if
any benefits. The current implementation should be simple to understand
and use.

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