Re: [boost] Re: [Libcwd-devel] libcwd and Boost

From: Carlo Wood (carlo_at_[hidden])
Date: 2002-08-30 09:34:42

On Fri, Aug 30, 2002 at 10:01:12AM -0400, Rob Stewart wrote:
> I still don't see the point.  The library code can allocate and
> deallocate memory as it sees fit.  It can use new/delete,
> std::allocator<...>, or whatever.  As long as the library doesn't
> allocate memory and hand it off to the caller, or if the memory
> allocation is managed in an object that defers to the library to
> release it, there is no problem.

The reason I need this is because I have written a debugging
library that needs to be able to do demangling from within malloc().

The default std::allocator will call malloc() to enlarge its memory
pool, a pool that is being used by EVERYTHING that uses the default
allocator (like all STL without specifying specifically an allocator).

I need to make a distinction between memory allocated by 'the user'
and by the debugging library however, so I cannot have the library
use the default memory pool.  Moreover, per memory pool, libstdc++
sets a lock - so using std::allocator from within malloc() will
cause a dead lock sooner or later (sooner).

Summary: Because I want to be able to use the demangler in debug
code, also from within a call to malloc, or an overridden operator
new, I cannot use the default allocator at all, anywhere, during
the demangling routine.  An interface that uses std::string will
have to be a wrapper around the demanger that uses its own memory
pool.

Now - if the allocator used by the demangler is to be specified
as a template parameter then its size will grow with a factor of
two when it is used from both 'debug library "space"' and 'user space':
the debug library will provide its own allocator and the user
will just use the default allocator.  Therefore I'd prefer passing
an allocator during link time rather than compile time - also because
that speeds up compiling applications that use this library, of course.

The idea then is to pass a reference to an object that specifies
how to allocate things and use internally a customized allocator
that will use this object instead.  The external interface then
becomes rather unusual though: one would have to define a global
object that the library will link with in order to become complete.

Another solution would be that the user of the library would provide
a wrapper himself: Determines the allocator he wants to use, and
instantiate the demangler code into a *.o file that provides the
final interface for himself.  In that case we CAN make the demangler
library just a template library I suppose.

-- 
Carlo Wood <carlo_at_[hidden]>