Re: [boost] [exception] ostringstream like

Subject: Re: [boost] [exception] ostringstream like
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-08-15 15:25:50

On Sun, Aug 15, 2010 at 11:56 AM, David Abrahams <dave_at_[hidden]> wrote:
> At Sun, 15 Aug 2010 11:26:30 -0700,
> Emil Dotchevski wrote:
>>
>> > and may fail to allocate the needed memory
>> > for the string and stream, thus maskign the initial
>> > exception with some bad_alloc.
>>
>> This concern is not valid because the C++ standard permits the
>> runtime code
>
> Do you mean the runtime library?

No, I mean the generated code.

>> to run out of memory while trying to throw an
>> exception, which presumably may result in a std::bad_alloc.
>
> If not, I don't think that invalidates the concern at all.  It's
> application- dependent whether or not the originally-intended
> exception is more important information than the knowledge that memory
> was running short at the point of the throw.
>
> If so, I wouldn't presume that it would throw bad_alloc in that case,
> in real implementations.  Usually this sort of thing falls under
> "violating implementation limits" and invokes undefined behavior.

Stroustrup, The C++ Programming Language, Special Edition, page 371:

"Throwing an exception requires an object to throw. A C++
implementation is required to have enough spare memory to be able to
throw bad_alloc in case of memory exhaustion. However, it is possible
that throwing some other exception will cause memory exhaustion."

This stops short of saying that it might result in a std::bad_alloc
but it seems permitted.

Since throwing (anything other than std::bad_alloc) can fail, you can
think of the postcondition of throwing an exception to be that the
exception was thrown successfully. Exceptions being the usual way to
enforce postconditions, I think it is natural to permit a different
exception to propagate instead.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode