std::string exorcism hiccup

[Loren James Rittle]

>> I come across a major stumbling block.

>> The standard exceptions use std::string internally to store their 
>> descriptions.
[...]
>> (However ios_base::failure stores its description in a char[256])
[...]
> I don't know what to say, except that this does seem like a serious
> problem. Hopefully somebody clever can come up with a solution.

I took a look at the cited case this afternoon.  I have to agree that
it might require some thought to handle well on embedded platforms
under some usages (especially under hard memory limits).

But questions came to mind: how many exceptions are active at once?
how large are these strings used in the std::.*_error exceptions in
nominal cases?

> Would it be possible for you to submit an example C++ program or simple
> test case that clearly demonstates the issue to this list? That might be
> a good place to start.

This example is a proxy for the issue:

#include <stdexcept>
#include <iostream>

int main (void)
{
  try
    {
      throw std::logic_error ("why not");
    }
  catch (std::logic_error x)
    {
      std::cout << x.what() << std::endl;
    }
}

Sure enough, within the implementation for logic_error, there is a use
of string<> that by default will attempt to grab small memory requests
from the SGI caching allocator.

This exact example allocates a 960-byte chunk of memory (i.e. 40
24-byte regions) which will never be released back to the OS.

If the error text was over 24 bytes (I suspect that it might be for
some throw situations but I didn't check), a larger non-returnable
allocation would occur.

OK, I don't claim to be clever enough to post a solution this issue in
the context of a 5-minute e-mail, but I'd agree that this internal
implementation policy should be more tunable for embedded platforms.
The problem is that most traditional solutions to this problem would
require a complete recompilation of the library... (In fact, I must
concede that the __USE_MALLOC recompilation option might be the best
case for tiny embedded systems; since by starving themselves of
memory, they have all but agreed to the Faustian pact with the Devil)

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672