Re: [boost] Demangler; Getting there...

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-01 12:13:01

From: "David Bergman" <davidb_at_[hidden]>

> Passing a memory allocator to a demangler...
>
> Maybe we should enforce this to every library in Boost which could
> potentially be used in a memory-tight context ;-)
>
> What is this? I hope someone with more Boost muscles than I raises
> his/her voice so we can have tools do what they are supposed to do, and
> not being forced to pass allocators around...

Cool it, David. The fact that "right" answer is obvious to you doesn't mean
it's obviously right for everyone. Carlo has a point: this demangling
facility is a special-purpose tool and his concern with tight memory
situations is not misplaced.

> And, as someone else pointed out, the only way to protect a
> "memory-critical" library is to preallocate memory, changing memory
> scheme will not work.

There are lots of possible approaches, depending on your target platform
and environment.

> So, if a library is expected to be used in
> memory-critical situations (or allocate huge chunks of data), it should
> (through a static "init" or similar method) allocate a huge chunk of
> data for internal management early in the process' life.

Normally for error reporting I'd deal with this at an application level, by
only trying to demangle names once the stack has unwound and a certain
amount of memory has been reclaimed. However, I can understand that this
might not be appropriate for some applications. For instance, if I wanted
to record the stack backtrace at the point bad_alloc was being thrown I'd
be out-of-luck. I'm not sure that the allocator approach would be
sufficient to solve this problem...

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com