From -6786007895958773150 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c79715c6d9945c29 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-11-17 23:34:06 PST Newsgroups: comp.std.c++ Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hpscdc!vinoski From: vinoski@ch.apollo.hp.com (Stephen Vinoski) Subject: Re: return values and destructors Message-ID: Sender: news@scd.hp.com (News Account) Organization: Hewlett-Packard Corporation, Chelmsford, MA References: <1992Nov12.132254.1@vax1.bham.ac.uk> <1992Nov17.204640.9222@microsoft.com> Date: Wed, 18 Nov 1992 14:56:36 GMT Lines: 44 In article <1992Nov17.204640.9222@microsoft.com> jimad@microsoft.com (Jim Adcock) writes: >In article 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.