🚀 go-pugleaf

In article <1992Nov17.204640.9222@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <BxMxxB.CMp@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>|There is also a similar potential problem with exceptions and throw
>|statements; what happens if the value of the thrown object is affected
>|by the destructors executed due to stack unwinding before the throw
>|actually occurs?
>
>I still believe you're being confused by a compiler bug.  Can you quote
>ARM to support your position?  Seems clear to me that a throw expression
>has to be evaluated in scope, which means it must be evaluated before
>the destructors, since destructors occurs on exiting scope.  Once the
>throw expression has been evaluated, the throw object *has* its value, 
>and the destructors can do what they want without affecting its value.

I don't think that "confusion" is the correct term since I also
believe this to be a compiler bug.  My comment about thrown objects
was an attempt to show how ridiculous it is for return expressions to
be affected by destructors of local objects.  Remember, not everyone
posting to this thread agrees that this is a problem.

I want to ensure that the interpretation of this problem as a compiler
bug is correct given what the ARM says on page 90 about how return
works.

>Likewise on return values.  The return expression must be evaluated in
>scope which means it must be evaluated before the dtors so it must already
>*have* its value by the time scope is exited and dtors are executed.
>If the return object tries to get its value after dtoring its a compiler bug,
>since the dtoring implies scope has already been exited so then how could
>the return expression be being evaluated in scope?

You're preaching to the choir. :-)  I agree with you 100%.  I just
want somebody on the ANSI C++ committee to sit up and take notice of
this problem (yes, I have already notified the rep from my company).
This behavior should be more clearly specified by the language
standard.

I will consider this to be a cfront bug and report it as such.

-steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.