Boost logo

Boost :

From: shiwei xu (xushiweizh_at_[hidden])
Date: 2008-04-30 12:47:34

Hello all,

Recently I write a new class named "boost::gc_alloc" (see
Here is its specification:

class gc_alloc
  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 (,
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

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:

On Fri, Apr 25, 2008 at 9:55 PM, <Lance.Diduck_at_[hidden]> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at