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

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-01 13:22:05

Dave,

There is no need to cool me; I appreciate that Carlos tool will be used
in memory critical situations, and that there could be reasons to be
cautious with memory allocation.

I do not want a Boost.Demangle to use allocator parameters without at
least a discussion.

I saw a proposal using streams, which at least would void the need to do
the "external" allocation for the string object. The internal memory
management, necessary for the demangling process, is a different story.
Unfortunately, stack allocation, as suggested by someone, would probably
not be a good choice; the debugging might be needed in tight stack
situations, such as deep recursions.

The *only* solution I see is to preallocate memory for internal
purposes, no matter what target platform and processor architecture; I
might need some further insight here, since you said there are lots of
possible approaches.

Regards,

David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
Sent: Sunday, September 01, 2002 1:13 PM
To: boost
Subject: Re: [boost] Demangler; Getting there...

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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost