Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-09-26 17:30:53
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.
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk