Hello all, Recently I write a new class named "boost::gc_alloc" (see http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/gc_alloc...). Here is its specification: class gc_alloc { public: gc_alloc(); // same as: gc_alloc(tls_block_pool::instance()); gc_alloc(block_pool& pool); // initialize by given a pool instance gc_alloc(gc_alloc& a); // initialize by given a indirect pool instance ~gc_alloc(); // clear void* allocate(size_t cb); // allocate memory without cleanup function void* allocate(size_t cb, destructor_t fun); // allocate memory with cleanup function void deallocate(void* p, size_t cb); template <class Type> void destroy(Type* obj); template <class Type> void destroyArray(Type* array, szie_t count); void clear(); // cleanup and release all memory allocated by the allocator void swap(gc_alloc& o); // swap two instances }; Comparing with boost::scope_alloc ( http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/scoped_a...), It append these methods: { void deallocate(void* p, size_t cb); template <class Type> void destroy(Type* obj); template <class Type> void destroyArray(Type* array, szie_t count); } Yes, it allows you to delete objects manually. But this is OPTIONAL, not a MUST. You don't need to delete objects, if you don't want or forget to do. However, I have some additional NOTES: 1. boost::auto_alloc (its old name is "AutoFreeAlloc") and boost::scoped_alloc (its old name is "ScopeAlloc") are implemented for four years (from 2004). And they are widely used and tested. They are proved in practice. 2. boost::gc_alloc was implemented yesterday. It is complexer than boost::auto_alloc and boost::scoped_alloc. Is it useful? Maybe, but it needs to be proved itself. If you are interested in it, refer the source code: http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/gc_alloc... On Fri, Apr 25, 2008 at 9:55 PM, <Lance.Diduck@ubs.com> wrote:
I think the best thing to do is package up your allocators, and present them for a boost peer review. I have a strong interest in seeing more specialty allocators in C++ so I will be glad to help, and even donate some of my own, as I am sure others would to. Even bringing up HeapLayers to boost quality standards would be worthwhile.
There are lots of ways of getting C++ classes and libraries to use specialty allocators, but hardly any allocators nor docs on why you might want to. Nor ways to actually write an allocator that could be used in a library. For some reason people attach a lot of unwarranted hype to GC and allocators -- esp to try and sell new "revolutionary" programming models. Sigh. All we really need is a library of allocators and ways to apply them without getting in trouble, and keep them out of sight when I don't care. That is all the innovation I want.