Hi Degski, Thanks for your time.
Playing around with devector, I find the default growth strategy (x4) > rather (too) agressive. It also has some in my view un-intended effects. Starting from let's say initial front and back capacities of each 4, now adding 5 elements in front and 5 elements in the back (so 10), now gives me a devector with capacity 128 (wow, why bothr with SBO at all).
There is room for improvement here. https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md recommends 1.5. But if I used it as a local buffer, a bigger value might be warranted (so at least the user can choose).
Then looking how the free_capacity is split between front and back we get 95 and 23 (or the other way around, depending on whether we first push_back or first push_front, even when front- and back-pushes are interleaved). As we are multiplying by 4, this will become more and more skewed.
Yeah, but would it not become more and more skewed no matter what number
1 we multiply with?
Is there any way to avoid that? Is it desirable to avoid that? The analog for vector is that it has (with a growth factor of 2) on average 25% unused objects. As the container grows, so does the wasted space in absolute terms.
Some bikeshedding (tm). I don't like any of the names much. The batch_deque *is* a deque, it should be called that way. devector is a hybrid vector/deque, I think veque would capture that. Then as to double_ended, I think it's too long and describes badly what we are talking about. I haven't got any (much) better proposal, but was thinking of Boost.Que, nice and short.
i.e. boost::que::veque and boost::que::deque.
I think it's great to do some bikeshedding. Keep doing that. kind regards Thorsten