Re: [boost] [devector] optimum growing/insertion policy

Subject: Re: [boost] [devector] optimum growing/insertion policy
From: Soul Studios (matt_at_[hidden])
Date: 2017-11-08 22:42:44

> OK, now I get it. Well, my position is that reserve should be replaced by
> some mechanism for explicitly controlling free space at each end. Then 
> the user
> can rely on the guarantee that she can do as many as
> [back|front]_free_capacity() push_[back|front] ops without rellocation.

So, reserve_front(), reserve_back()? I mostly get your 
growth/reallocation strategy as-described but I think at this point you 
have to start to question the purpose.
With a deque-like segmented structure you could allocate multiple blocks 
using reserve and then assign them to the back or front depending as needed.

Looking at the performance of GCC's deque implementation, you're not 
going to lose significant iteration performance if this is done right, 
asides from for large types 
(http://www.plflib.org/benchmarks_haswell_gcc.htm#rawperformance).