On Mon, Jun 8, 2009 at 11:51 PM, Christian Schladetsch<christian.schladetsch@gmail.com> 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