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