home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12688 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.4 KB
  1. Path: sparky!uunet!rde!gator!fang!att!allegra!alice!ark
  2. From: ark@alice.att.com (Andrew Koenig)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <23507@alice.att.com>
  6. Date: 20 Aug 92 21:16:28 GMT
  7. Article-I.D.: alice.23507
  8. References: <BszApE.49v@world.std.com> <1992Aug17.073500.24115@ericsson.se> <23466@alice.att.com> <3920@starlab.UUCP> <23487@alice.att.com> <TMB.92Aug20142610@arolla.idiap.ch>
  9. Reply-To: ark@alice.UUCP ()
  10. Organization: AT&T Bell Laboratories, Murray Hill NJ
  11. Lines: 21
  12.  
  13. In article <TMB.92Aug20142610@arolla.idiap.ch> tmb@idiap.ch writes:
  14.  
  15. > You can avoid unexpected behavior involving temporaries by programming
  16. > defensively. In particular, this means: do _not_ return a reference or
  17. > pointer to an explicit or implicit argument or its contents (*this,
  18. > call-by-value, call-by-reference). Furthermore, do _not_ define cast
  19. > operators to pointer types in your classes (instead, make them normal
  20. > member functions that you have to call explicitly).
  21.  
  22. I wish life were that simple.  The trouble comes with expressions like
  23.  
  24.     foo().bar().baz()
  25.  
  26. where bar returns *this.  If an implementation is allowed to delete the
  27. result of foo() before calling baz, the roof can cave in even if your
  28. defensive rules are followed.  That is enough to argue, at least for me,
  29. that the current rule of allowing temporaries to be destroyed as soon as
  30. they are fetched, is too liberal.
  31. -- 
  32.                 --Andrew Koenig
  33.                   ark@europa.att.com
  34.