home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12555 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  1.8 KB
  1. Path: sparky!uunet!van-bc!rsoft!agate!ames!elroy.jpl.nasa.gov!usc!wupost!gumby!yale!mintaka.lcs.mit.edu!bloom-beacon!eru.mt.luth.se!lunic!sunic!lth.se!newsuser
  2. From: dag@control.lth.se (Dag Bruck)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug19.111836.25070@lth.se>
  6. Date: 19 Aug 92 11:18:36 GMT
  7. References: <1992Aug17.073500.24115@ericsson.se> <23466@alice.att.com> <1992Aug17.211508.6634@lucid.com> <1992Aug18.205211.16789@Warren.MENTORG.COM> <TMB.92Aug19113657@arolla.idiap.ch>
  8. Sender: newsuser@lth.se (LTH network news server)
  9. Organization: Department of Automatic Control, Lund, Sweden
  10. Lines: 25
  11.  
  12. In <comp.lang.c++> tmb@idiap.ch writes:
  13. >The properties of temporaries are no different (and no worse) than the
  14. >properties of automatic variables: pointers to them become invalid
  15. >when the object disappears.
  16.  
  17. I think there is a major difference.  The programmer controls the
  18. scope of automatic variables and hence their lifetime.  Temporaries
  19. are created by the compiler (possibly because of ill-advised
  20. programming techniques) and the programmer has no control over their
  21. lifetime.
  22.  
  23. The language does not specify under what circumstances temporaries are
  24. created, and I'm willing to accept that, but it should at least
  25. specify their lifetime in expressions that potentially create
  26. temporaries.
  27.  
  28. Given the deliberations for and against different models [no details
  29. given] I would probably prefer destruction at greatest enclosing
  30. expression, with the additional constraint that temporaries created in
  31. one "arm" of a conditional expression are destroyed at the end of that
  32. conditional expression.
  33.  
  34. With respect to difficulty of implementation, in particular combined
  35. with exception handling, it would probably pay off to look at existing
  36. implementations (I can think of HP and IBM) before making any judgements.
  37.