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.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk