From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-12-04 12:03:53
> > [Gary Powell]
> > the pool can't go away until all of the memory allocated of a specific
> > does. It's not exactly what I would have wished for. Does anyone else
> > any specific data on this sort of shared pool technique?
> Actually, when using the pool allocator interface, the pool won't go away
> until after main() exits :).
This should be noted in the documentation, because it would prevent me from
using it as is. :< (The note could easily contain the next two statements.)
In games there are specific times when you have an opportunity to clean up
memory usage. (Between levels etc.) And often the memory requirements are
> There are two ways around this:
> 1) Add a function to sized_pool to allow freeing of memory blocks that
> don't have any chunks. This could also be useful to call in low-memory
> conditions. This is on the "future feature" list.
> 2) Try to implement another allocator interface based on a "shared pool"
> -- literally, it may be possible to base it on shared_ptr<sized_pool>.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk