From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-30 13:08:20
At 11:53 AM 8/30/2002, Thomas Wenisch wrote:
>On Fri, 30 Aug 2002, Daniel Frey wrote:
>
>> Rob Stewart wrote:
>> >
>> > Given that your demangling logic will be invoked in almost every
>> > use case strictly for error reporting, performance is not an
>> > issue. Therefore, any performance concern wrt copying strings is
>> > moot.
>>
>> It's not just about performance. Errors may occur when the system is
>> short of memory, thus you should try be avoid memory allocations
>> whenever possible (OK, string will most likely not be a real problem,
>> put you never know...).
>>
>> Regards, Daniel
>>
>
>I think Daniel has a really good point here. If you really intend to use
>the demangler in a hard-core debug library (ie debugging code in a
>memory-constrained embedded system), then it is important that the debug
>code does not allocate ANY memory or other resources at the time an error
>is detected - resources/memory need to be reserved in advance.
>
>By the same token, I think that it is a LOT of work to get a demangler
>that only uses pre-allocated memory, and it may not even be possible, so
>I'm not sure that this should be a design goal of a general-purpose name
>demangling library. Such a demangler would probably have to be tightly
>integrated with the rest of your debugging framework (ie stack trace
>capture without allocating memory, exceptions that use pre-allocated
>memory, etc). Since this is not the most common use case, IMHO, I believe
>the extremely low memory situation should not be a primary concern now.
It is not that hard to ensure that all tempory buffers needed
by the demangler are allocated on the stack.