home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / std / cplus / 1550 < prev    next >
Encoding:
Text File  |  1992-11-12  |  2.7 KB  |  63 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!pipex!warwick!bham!bhamvx!mccauleyba
  3. From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
  4. Subject: Re: return values and destructors
  5. Sender: usenet@rs6000.bham.ac.uk (USENET News Service)
  6. Message-ID: <1992Nov12.132254.1@vax1.bham.ac.uk>
  7. Date: Thu, 12 Nov 1992 13:22:54 GMT
  8. Lines: 51
  9. References: <BxKs87.417@scd.hp.com> <1dsevkINNe8t@agate.berkeley.edu>
  10. Organization: University of Birmingham
  11.  
  12. In article <1dsevkINNe8t@agate.berkeley.edu>, jbuck@forney.berkeley.edu (Joe Buck) writes:
  13. > In article <BxKs87.417@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
  14. >>"A return statement with an expression can be used only in functions
  15. >>returning a value; the value of the expression is returned to the
  16. >>caller of the function."
  17. >>
  18. >>Given the statement
  19. >>
  20. >>    return foo;
  21. >>
  22. > 
  23. > [ example deleted: it's designed so that the destructor of an auto
  24. >   variable will alter foo's value. ]
  25. > 
  26. > Your example is the kind of thing that I think language standards should
  27. > leave explicitly undefined; otherwise compiler vendors will have to
  28. > generate worse code just in case someone like you gets tricky. :-)
  29. >
  30.   [...]
  31.  
  32. >>Is this a cfront bug?
  33. > 
  34. > Again, I don't think so.  I'm not willing to pay the cost of the
  35. > extra copy operation that might be required were the committee to
  36. > force your example to work.  It's simply not worth slowing down reasonable
  37. > C++ programs to have defined behavior on your unreasonable example (it is
  38. > cute, though)...
  39.  
  40. I beg to differ I think that the behaviour of Cfront is a bug and that the
  41. statement in the ARM is unambiguous if a little opaque. The redundant copy will
  42. only be avoidable in cases where the return type is an inbuilt type and the
  43. overhead of evaluating this before calling destructors and storing it away
  44. somewhere is minimal. Also the return expression would have to not contain any
  45. class types or even function calls as any class operation even on a object that
  46. is not local may legitamately make use of local objects. (Consider a class that
  47. has a static `population' member that is the total number of objects currently
  48. existing. I agree the original example was contrived but I don't think it
  49. should break a good complier. 
  50.  
  51. Some compilers offer optimization switches with names like "assume no pointer
  52. aliasing" which allow them to make this sort of optimisation at the risk of
  53. miscompiling this sort of perverse example. I do not think a compiler should
  54. make unsafe optimisations unless the programmer has invited it to do so.
  55. -- 
  56.     \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
  57.  .  _\\__[oo 
  58. .__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
  59. .  l___\\        Fax: +44 21 625 2175
  60.  # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
  61. ###LL  LL\\     ICBM: 52.5N 1.9W
  62.  
  63.