Re: [boost] Question for C++ experts about exception allocation failure

Subject: Re: [boost] Question for C++ experts about exception allocation failure
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-05-20 12:37:36

On Wed, May 20, 2009 at 2:45 AM, Peter Bindels <dascandy_at_[hidden]> wrote:
> Hi,
>
> 2009/5/18 Anthony Williams <anthony.ajw_at_[hidden]>:
>> I don't think exception objects are allocated on the stack in MSVC, and
>> I don't see how they could be --- if an exception is caught then before
>> the handler is entered the stack needs to be unwound and all the
>> destructors run. Having an exception object lurking halfway down the
>> empty stack space would just confuse things no end.
>
> I debugged this once to find out what's what exactly and it is halfway
> down the stack. The stack below it is unwound but it is not freed
> until the end of the exception handler. The exception handler executes
> on the stack just above (below) the exception, and the exception is
> destroyed and the stack below it freed when it's done. This all is
> based on empirical measurement.
>
> When I figured it out it seemed like a good solution, except for the
> case where you have just unwound a big stack and build up a new big
> stack inside an exception handler. That seems an off-case that isn't
> worth the trouble though.

It's possible that the compiler uses some logic at run-time, after the
exception has been caught, to determine if the exception should be
copied elsewhere (as in "would it leave too big of a gap in the stack
if it's left there?) I'm saying this because, if I remember correctly,
MSVC is careful to keep a pointer to the exception object copy
constructor (so it can clone it) which seems pointless if the object
is created on the stack and never copied elsewhere.

Also, I've been wondering why the C++ standard requires that
exceptions have nothrow copy constructor -- that isn't necessary if
the object is copied once only at the time of the throw -- but this
requirement enables the behavior I described.

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