home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / std / cplus / 1547 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.1 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: 12 Nov 1992 02:19:32 GMT
  6. Organization: U. C. Berkeley
  7. Lines: 50
  8. Message-ID: <1dsevkINNe8t@agate.berkeley.edu>
  9. References: <BxKs87.417@scd.hp.com>
  10. NNTP-Posting-Host: forney.berkeley.edu
  11.  
  12. In article <BxKs87.417@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
  13. >"A return statement with an expression can be used only in functions
  14. >returning a value; the value of the expression is returned to the
  15. >caller of the function."
  16. >
  17. >Given the statement
  18. >
  19. >    return foo;
  20. >
  21. >where foo is an object with some value, does the statement from the
  22. >ARM mean that the compiler *must* return the value that foo has in the
  23. >return statement, rather than the value foo might have at some point
  24. >after the destructors for local automatic objects have been executed?
  25.  
  26. [ example deleted: it's designed so that the destructor of an auto
  27.   variable will alter foo's value. ]
  28.  
  29. Your example is the kind of thing that I think language standards should
  30. leave explicitly undefined; otherwise compiler vendors will have to
  31. generate worse code just in case someone like you gets tricky. :-)
  32.  
  33. >Shouldn't both of these cases perform the same way?
  34.  
  35. I don't think so (if that means a change is required in the draft
  36. standard, so be it).
  37.  
  38. >Is this a cfront bug?
  39.  
  40. Again, I don't think so.  I'm not willing to pay the cost of the
  41. extra copy operation that might be required were the committee to
  42. force your example to work.  It's simply not worth slowing down reasonable
  43. C++ programs to have defined behavior on your unreasonable example (it is
  44. cute, though).  There is already precedent: the ANSI
  45. C standard leaves the order of side effects explicitly undefined in
  46. examples like
  47.  
  48.     void func(int,int);
  49.     int i = 3;
  50.     func(i++,i++);
  51.  
  52. The ARM statement needs amendment in any case, as it says elsewhere that
  53. the copy constructor is called to return objects, and there is no
  54. guarantee that the user will write a proper copy constructor.
  55.  
  56.  
  57.  
  58.  
  59.  
  60. --
  61. Joe Buck    jbuck@ohm.berkeley.edu
  62.