From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-09-01 21:47:25
One trick, on the many platforms that support it, is to use alloca.
Another trick is to recurse through a wrapper with a big enough
At 07:33 PM 9/1/2002, Carlo Wood wrote:
>On Sun, Sep 01, 2002 at 08:43:03AM -0600, Greg Colvin wrote:
>> Low memory can be a big issue in debugging code, so I'll
>> repeat my suggestion that the demangler functions use only
>> stack-allocated memory.
>Someone else said that tight heap and tight stack issues
>are related - therefore pre-allocation seems a better
>solution than stack allocation.
>It would be pretty hard to only use stack allocated memory,
>I think. Let me give some internal details.
>What is needed are three vectors:
> internal_vector<int> M_template_arg_pos;
> internal_vector<substitution_st> M_substitutions_pos;
> internal_vector<qualifier_ct> M_qualifier_starts;
>one for template arguments, one for substitutions
>and one for qualifiers.
>sizeof(substitution_st) == 12
>sizeof(qualifier_ct) == 12 + sizeof(internal_string)
>What is according to you the maximum number of
>template arguments, substitutions and qualifiers in a type?
>The code also uses about 25 internal strings.
>Each of these strings might need an arbitrary size,
>and we should let them all be of the order of the
>output string I'd guess. How long is the longest
>demangled name? I've seen a few as big as a whole
>17" screen full (1024x768). We could use 2 kb for
>each internal string (although some are local variables
>in recursively called functions) but even that MIGHT
>not be enough in certain cases...
>The point is that the actual size of memory needed
>is not related to the demangler code, but to the
>application and its circumstances. And so is the
>needed memory model.
>By simply allowing the user to pass an Allocator
>parameter for the most general interface, they can
>deal with this issue themself (pre-allocation, seperate
>memory pool or whatever) and adjust the load on their
>resources according to their need.
>Stack allocation could be implemented through a
>"pre-allocated" memory pool in the first call (a wrapper).
>Actually, I think that allocators like this should
>be part of boost too, and NOT as a part of my demangler
>library, but provided seperately.
>Carlo Wood <carlo_at_[hidden]>
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk