home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12708 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.5 KB  |  58 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug20.095429.29845@mole-end.matawan.nj.us>
  6. Summary: Not quite
  7. Organization: :
  8. References: <1992Aug17.073500.24115@ericsson.se> <23466@alice.att.com> <1992Aug20.092752.29529@mole-end.matawan.nj.us>
  9. Date: Thu, 20 Aug 1992 09:54:29 GMT
  10. Lines: 46
  11.  
  12. In article <1992Aug20.092752.29529@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:
  13. > In article <TMB.92Aug19113657@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  14. > > In article <1992Aug18.205211.16789@Warren.MENTORG.COM> adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
  15. > > 
  16. > >    So why would the ARM consider the example with a temporary sufficient
  17. > >    reason to reject the "end of function" approach? To me it appears that
  18. > >    the "end of function" approach for temporaries would not cause any more
  19. > >    difficulties or program bugs than those that can already occur even without
  20. > >    temporaries. So why not reconsider that approach?
  21. >  
  22. > > I don't want my temporaries to hang around until the end of the
  23. > > function. ...
  24.   
  25. > > Temporaries should get destroyed as soon as their value has been used.
  26. > > To make call-by-reference a little more convenient, there is a special
  27. > > rule for binding references to temporaries, and I guess that's OK.
  28.  . . .
  29. > Here's a thought.  There was, at one time, a suggestion for an `operator
  30. > void()' that describes the action of throwing away a value.  It gets used
  31. > for anything except the intialization of an object.  Would the `operator
  32. > void()' concept describe the point at which the temporary must be
  33. > discarded?
  34.  
  35. No, I'm wrong.  It's not quite enough because of the conditional
  36. context.  We have to specify the scope of the `thing' to which that
  37. value is bound in the conditional context.
  38.  
  39. I'm inclined to say that it's the conditional part itself, just as
  40. in a function, the parameter is bound to something whose lifetime is
  41. that of the function, and any temporary expression can be destroyed
  42. thereafter.
  43.  
  44. That, by the way, is different from the object created by the
  45. constructor here:
  46.  
  47.     int zot = Cthulu( 0 ).somefunc();
  48.  
  49. The object created is voided after the member function call, or after
  50. that function call's value is bound to the initialization ...
  51.  
  52. (Of course, that messes up member functions that return  *this . ...)
  53. -- 
  54.  (This man's opinions are his own.)
  55.  From mole-end                Mark Terribile
  56.  
  57.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  58.