|
Boost : |
From: Carlo Wood (carlo_at_[hidden])
Date: 2002-09-01 20:33:38
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]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk