home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12558 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.7 KB
  1. Path: sparky!uunet!van-bc!rsoft!agate!ames!elroy.jpl.nasa.gov!decwrl!deccrl!bloom-beacon!eru.mt.luth.se!lunic!sunic!ericom!falcon!jonas
  2. From: jonas@beppe.ericsson.se (Jonas Nygren)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug19.113554.5464@ericsson.se>
  6. Date: 19 Aug 92 11:35:54 GMT
  7. References: <TMB.92Aug19113657@arolla.idiap.ch>
  8. Sender: news@ericsson.se
  9. Reply-To: jonas@beppe.ericsson.se
  10. Organization: Ericsson Telecom AB
  11. Lines: 55
  12. Nntp-Posting-Host: falcon.ericsson.se
  13.  
  14. In article 92Aug19113657@arolla.idiap.ch, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  15. > In article <1992Aug18.205211.16789@Warren.MENTORG.COM> adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
  16. > 
  17. >    So why would the ARM consider the example with a temporary sufficient
  18. >    reason to reject the "end of function" approach? To me it appears that
  19. >    the "end of function" approach for temporaries would not cause any more
  20. >    difficulties or program bugs than those that can already occur even without
  21. >    temporaries. So why not reconsider that approach?
  22. > 
  23. > I don't want my temporaries to hang around until the end of the
  24. > function. I often use large temporaries (megabytes), and I see no
  25. > reason why they should stick around any longer than I need them.
  26. > 
  27. > Temporaries should get destroyed as soon as their value has been used.
  28.  
  29. Yes used is the right word. I gave a small example in a previous posting where
  30.  
  31.     s2 = s1.sub(2,3);
  32.  
  33. is OK, but
  34.  
  35.     s2 = s1.sub(2,3).strip();
  36.  
  37. is not. Why should this use be disallowed??
  38.  
  39. > To make call-by-reference a little more convenient, there is a special
  40. > rule for binding references to temporaries, and I guess that's OK.
  41.  
  42. Why is this use OK, on what is your 'guessing' based??
  43.  
  44. > 
  45. > The properties of temporaries are no different (and no worse) than the
  46. > properties of automatic variables: pointers to them become invalid
  47. > when the object disappears.
  48.  
  49. This is obvious. What we are discussing are when temporaries should disappear.
  50.  
  51. > 
  52. > If you want to be able to implement anything more powerful, you need
  53. > (surprise!) garbage collection (as stated in the ARM, p. 268). In the
  54.  
  55. If you read the referenced pages closely there are many points of destruction
  56. which are discussed and each giving some more 'power'. The ultimate solution
  57. might be GC. But without GC in the language we could try to make the language
  58. more 'intuitive' by  defining a reasonable behaviour for temporaries.
  59.  
  60. > presence of GC, you would then actually have a choice of destroying
  61. > the temporary yourself (the current situation, safe if no pointers to
  62. > it have been handed out), or of not destroying it at the end of the
  63. > expression and letting the GC take care of it.
  64. > 
  65. >                     Thomas.
  66.  
  67.  
  68. /jonas
  69.