home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12691 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.3 KB
  1. Path: sparky!uunet!olivea!hal.com!decwrl!sdd.hp.com!cs.utexas.edu!devnull!rgp
  2. From: rgp@mpd.tandem.com (Ramon Pantin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <2285@devnull.mpd.tandem.com>
  6. Date: 21 Aug 92 02:54:45 GMT
  7. References: <1992Aug17.073500.24115@ericsson.se> <TMB.92Aug20142610@arolla.idiap.ch> <1992Aug20.190313.3407@lucid.com>
  8. Sender: news@devnull.mpd.tandem.com
  9. Organization: Tandem Computers, Micro-Products Division
  10. Lines: 43
  11.  
  12. In article <1992Aug20.190313.3407@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
  13. >In article <TMB.92Aug20142610@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  14. >
  15. >|> Let me put in another vote for leaving things the way they are.
  16. >|
  17. >
  18. >There may be some confusion about where we are now. The ARM (and the
  19. >x3j16 working paper) give compilers a lot of freedom about where
  20. >to destroy temporaries. 
  21. >
  22. >This is generally considered unsatisfactory because it means
  23. >that programs frequently break when move between compilers with
  24. >different strategies.   If all compilers were making the same
  25. >or similar choices in this area x3j16 could just standardize that
  26. >decision. The reason this didn't happen is that there are good arguments
  27. >for a variety of different strategies. 
  28.  
  29. I've got a simple (poor man's?) solution to this problem:
  30.  
  31.     Let the compiler destroy temporaries as soon as it wishes
  32.     to do so, with the exception of objects for which a member function
  33.     that has been declared with a new keyword (say "longlived")
  34.     _might_ have been executed, in which case the object persist
  35.     until the end of the function (or some other convenient
  36.     place for destruction).
  37.  
  38.     Member functions that return pointers or references to their
  39.     internal data structures would be declared as "longlived".
  40.     The "_might_ have been executed" above would allow enough
  41.     freedom to the compiler implementation to make choices such as:
  42.  
  43.         - Add some logic to the compiler to determine if
  44.           any of the "longlived" methods are invoked (maybe
  45.           even some flow control analysis could be done).
  46.  
  47.         - Always destruct objects that have any member function
  48.           that is "longlived" at the end of the function even
  49.           if none of them are invoked in the body of the function.
  50.           (Maybe classes themselves could be declared as "longlived")
  51.  
  52. What do you think? 
  53.  
  54. Ramon Pantin
  55.