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

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-01 17:43:32

Dave,

I forgot to apologize for the seemingly hard tone in "What is this?". I
hereby apologize for that hard tone (and, no sarcasm).

I would propose that

1. there is no allocator for "external" allocation (i.e., dealing with
the resulting demangled string)

2. the external API is stream-based

3. the internal allocation is (at least defaulted) to preallocation of a
block reasonably big to accommodate for the demangling algorithm and
interim resources.

The reason for not wanting the client to provide an allocator for the
internal use of the demangling algorithm is that he/she normally would
not have to know the inner details, and thus would not know (or need to
know) what kind of allocator would be beneficial in this case.

I mean, questions like "does the demangling require a lot of small
chunks or a few big ones", or "does it need the chunks in the beginning
or throughout the process" are questions that should not need to be
answered by clients.

/David 

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

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

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

That's fine, and it's a lot different from calling for "someone with
muscle" to step in so that "we can have tools that do what [you think]
they are supposed to do".

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

On lots of platforms, the stack and heap come out of the same pool, so
there's no distinguishing "tight heap" from "tight stack".

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

Well, allocators could be used to make preallocated memory available, if
that's your preferred solution. As I said before, I'm not convinced it's
the right answer, but I don't see why it's neccessarily wrong (yet),
either.

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

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