home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / cplus / 1596 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.7 KB  |  56 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hpscdc!vinoski
  3. From: vinoski@ch.apollo.hp.com (Stephen Vinoski)
  4. Subject: Re: return values and destructors
  5. Message-ID: <Bxx2uD.42x@scd.hp.com>
  6. Sender: news@scd.hp.com (News Account)
  7. Organization: Hewlett-Packard Corporation, Chelmsford, MA
  8. References: <1992Nov12.132254.1@vax1.bham.ac.uk> <BxMxxB.CMp@scd.hp.com> <1992Nov17.204640.9222@microsoft.com>
  9. Date: Wed, 18 Nov 1992 14:56:36 GMT
  10. Lines: 44
  11.  
  12. In article <1992Nov17.204640.9222@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  13. >In article <BxMxxB.CMp@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
  14. >|There is also a similar potential problem with exceptions and throw
  15. >|statements; what happens if the value of the thrown object is affected
  16. >|by the destructors executed due to stack unwinding before the throw
  17. >|actually occurs?
  18. >
  19. >I still believe you're being confused by a compiler bug.  Can you quote
  20. >ARM to support your position?  Seems clear to me that a throw expression
  21. >has to be evaluated in scope, which means it must be evaluated before
  22. >the destructors, since destructors occurs on exiting scope.  Once the
  23. >throw expression has been evaluated, the throw object *has* its value, 
  24. >and the destructors can do what they want without affecting its value.
  25.  
  26. I don't think that "confusion" is the correct term since I also
  27. believe this to be a compiler bug.  My comment about thrown objects
  28. was an attempt to show how ridiculous it is for return expressions to
  29. be affected by destructors of local objects.  Remember, not everyone
  30. posting to this thread agrees that this is a problem.
  31.  
  32. I want to ensure that the interpretation of this problem as a compiler
  33. bug is correct given what the ARM says on page 90 about how return
  34. works.
  35.  
  36. >Likewise on return values.  The return expression must be evaluated in
  37. >scope which means it must be evaluated before the dtors so it must already
  38. >*have* its value by the time scope is exited and dtors are executed.
  39. >If the return object tries to get its value after dtoring its a compiler bug,
  40. >since the dtoring implies scope has already been exited so then how could
  41. >the return expression be being evaluated in scope?
  42.  
  43. You're preaching to the choir. :-)  I agree with you 100%.  I just
  44. want somebody on the ANSI C++ committee to sit up and take notice of
  45. this problem (yes, I have already notified the rep from my company).
  46. This behavior should be more clearly specified by the language
  47. standard.
  48.  
  49. I will consider this to be a cfront bug and report it as such.
  50.  
  51. -steve
  52.  
  53. Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
  54. Distributed Object Computing Program
  55. Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
  56.