[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] double_ended - request formal review
From:       Thorsten Ottosen <tottosen () dezide ! com>
Date:       2016-08-23 14:06:25
Message-ID: 44c8bb3f-78f8-f41c-d586-38bc95eaaa04 () dezide ! com
[Download RAW message or body]

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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]