Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Cory Nelson (phrosty_at_[hidden])
Date: 2009-06-09 21:39:08

On Mon, Jun 8, 2009 at 11:51 PM, Christian
Schladetsch<christian.schladetsch_at_[hidden]> wrote:
> Hello,
>
> There is a need in high-performance realtime software to use containers that
> may only grow in size. These are typically reset at the end of each update
> cycle.
>
> The proposal here consists of a base 'monotonic allocator', which takes its
> storage from a buffer that you provide. Allocations are made from this
> buffer, and deallocation only calls an object's destructor; no actual
> memory-management is performed at all.
>
> This is very useful for realtime systems that have to do things like, for
> example, physics or renderering systems. These systems build up lists and
> other containers over the period of an update frame, however at the end of
> that frame the storage can just be reset.
>
> The benefit of using this system over a normal std::allocator is that memory
> is not fragmented, and memory allocation and deallocation is basically
> optimal.
>
> Within the package are:
>
> boost.monotonic.inline_storage
> boost.monotonic.list
> boost.monotonic.vector
> boost.monotonic.map
> boost.monotonic.set
> boost.monotonic.ptr_list
>
> I didn't bother adding the other ptr_* containers yet.
>
> The files for the proposal are in the vault at
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=MonotonicAllocator.zip&directory=&
> .
>
> I'd be happy to address any issues or comments. There are some improvements
> that could be made.
>

My largest complaint with C++ is that containers do not fit well with
high-perf low-overhead scenarios, so I'm very interested in seeing
something like this.

I would want to see it taken a step further though.  Overhead can be a
big deal for large objects, so re-implementing string and vector
completely (so that you don't have the pointer/capacity specified
twice, in container & allocator) would be a welcome change.  Let the
user specify storage manually and throw if you go over it.  Make
default copying just copy the pointers around instead of all data.

-- 
Cory Nelson
http://int64.org