Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at