home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / cplus / 1598 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.9 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!agate!forney.berkeley.edu!jbuck
  2. From: jbuck@forney.berkeley.edu (Joe Buck)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: return values and destructors
  5. Date: 18 Nov 1992 21:47:06 GMT
  6. Organization: U. C. Berkeley
  7. Lines: 30
  8. Message-ID: <1eedkqINN9i2@agate.berkeley.edu>
  9. References: <BxMxxB.CMp@scd.hp.com> <1992Nov17.204640.9222@microsoft.com> <Bxx2uD.42x@scd.hp.com>
  10. NNTP-Posting-Host: forney.berkeley.edu
  11.  
  12.  
  13. In article <1992Nov17.204640.9222@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  14. >>I still believe you're being confused by a compiler bug.  Can you quote
  15. >>ARM to support your position?  Seems clear to me that a throw expression
  16. >>has to be evaluated in scope, which means it must be evaluated before
  17. >>the destructors, since destructors occurs on exiting scope.  Once the
  18. >>throw expression has been evaluated, the throw object *has* its value, 
  19. >>and the destructors can do what they want without affecting its value.
  20.  
  21. In article <Bxx2uD.42x@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
  22. >I don't think that "confusion" is the correct term since I also
  23. >believe this to be a compiler bug.  My comment about thrown objects
  24. >was an attempt to show how ridiculous it is for return expressions to
  25. >be affected by destructors of local objects.  Remember, not everyone
  26. >posting to this thread agrees that this is a problem.
  27.  
  28. Well, I was one of those who said that it wasn't a problem, because I
  29. found the original example posted a bit contrived.  But Jim Adcock's
  30. argument has convinced me that I was wrong; the argument to "return"
  31. has to be evaluated before the destructors are evaluated, and the
  32. sloppiness on this issue that I was advocating (e.g. assume nothing
  33. about destructors that affect the return value in this way) was wrong
  34. and would make the exceptions facility very difficult to use.
  35.  
  36. The ARM and draft standard could make this clearer.
  37.  
  38.  
  39.  
  40. --
  41. Joe Buck    jbuck@ohm.berkeley.edu
  42.