Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at