Date: 2000-12-04 13:07:10
> > Actually, when using the pool allocator interface, the pool won't go
> > until after main() exits :).
> This should be noted in the documentation, because it would prevent me
> using it as is. :< (The note could easily contain the next two
> 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
> considerably different.
This is only a limitation of the pool allocator interface (using pools with
containers). The sized_pool and pool<> interfaces will free their memory on
destruction of the pool.
Heh, heh. I thought this *was* in the documentation, but looking again, I
see that it's not. Yes, I will certainly note this in the docs!
I intend to expose the pool_accessor "interface" that the pool allocators
use (so that user code can access the underlying pools of any pool
allocator). Then, after the "release unused memory" function is added to
sized_pool, you will be able to instruct those pools to release their memory
whenever you want. I think that's the best solution for your situation.
Want a quick hack? After the pool_accessor is exposed, just delete and
re-create in-place the underlying pool. As long as nothing's allocated out
of the pool, it would do the same as above.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk