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

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-30 09:55:51

At 08:34 AM 8/30/2002, Carlo Wood wrote:
>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).

The default allocator will call ::operator new(), which may or may
not call malloc().

>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).

So why not have the library create and manage it's own pool?

Does this really need to be parameterized?

>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':

I don't follow this.

>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.

So you provide source for your allocator interface, which the user
can compile and link if they want to, or replace if they want to?

>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.