home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12685 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.8 KB  |  72 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug21.005722.16573@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Aug17.211508.6634@lucid.com> <1992Aug18.205211.16789@Warren.MENTORG.COM> <TMB.92Aug19113657@arolla.idiap.ch>
  10. Date: Fri, 21 Aug 1992 00:57:22 GMT
  11. Lines: 59
  12.  
  13. In article <TMB.92Aug19113657@arolla.idiap.ch> tmb@idiap.ch 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. I often use large temporaries (megabytes), and I see no
  24. >reason why they should stick around any longer than I need them.
  25. >
  26. >Temporaries should get destroyed as soon as their value has been used.
  27.  
  28.     As ordinary rvalues, a value can only get used ONCE.
  29. But as lvalues that isnt so:
  30.  
  31.     int i;
  32.     (i=3)=4;
  33.  
  34. Here i gets assigned to twice. For ordinary objects this is always
  35. meaningless, but for class based objects the assignment
  36. could have arbitrary side effects. So I'm not so sure when
  37. the 'value' has been used---it is not the value but the object
  38. that is being accessed twice.
  39.  
  40.     s(i,j)="Hello";
  41.  
  42. Here the string s has operator()(int,int) applied to make a 
  43. substring object to which an assignment is subsequently done,
  44. and that assignment copies the string "Hello" into the string
  45. s. S itself could sensibly be an expression ...
  46.  
  47.     print( (s1+s2)(i,j)="Hello" );
  48.  
  49. so now how long does (s1+s2) have to last? Or is the above
  50. idiom bad news?
  51.  
  52. >
  53. >The properties of temporaries are no different (and no worse) than the
  54. >properties of automatic variables: pointers to them become invalid
  55. >when the object disappears.
  56.  
  57.     When is that?
  58. >
  59. >If you want to be able to implement anything more powerful, you need
  60. >(surprise!) garbage collection (as stated in the ARM, p. 268). 
  61.  
  62.     In other words, if you cant define a sensible
  63. length of time for temporaries to hang around on a static basis,
  64. then dont--define it dynamically.
  65.  
  66.  
  67. -- 
  68. ;----------------------------------------------------------------------
  69.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  70.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  71. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  72.