On Sun, Aug 15, 2010 at 11:56 AM, David Abrahams <dave@boostpro.com> 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