home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12603 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.6 KB
  1. Path: sparky!uunet!kithrup!stanford.edu!agate!bionet!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!mips!carbon!news.cs.indiana.edu!syscon!gator!fang!att!allegra!alice!ark
  2. From: ark@alice.att.com (Andrew Koenig)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Keywords: temporaries,destruction,statements,block,early
  6. Message-ID: <23487@alice.att.com>
  7. Date: 19 Aug 92 18:22:44 GMT
  8. References: <BszApE.49v@world.std.com> <1992Aug17.073500.24115@ericsson.se> <23466@alice.att.com> <3920@starlab.UUCP>
  9. Reply-To: ark@alice.UUCP ()
  10. Organization: AT&T Bell Laboratories, Liberty Corner NJ
  11. Lines: 57
  12.  
  13. In article <3920@starlab.UUCP> mi@starlab.UUCP (Michael Hoennig) writes:
  14.  
  15. > >For these reasons, I think a shorter lifetime than end of statement
  16. > >is appropriate for temporaries.  Whether the committee will go that
  17. > >way, however, remains to be seen.
  18.  
  19. > Why shorter, Andrew? Why not like all other automatic instances (those
  20. > on the stack) at the end of the block?
  21.  
  22. Three reasons:
  23.  
  24.     1. strict end of block destruction creates problems for programs
  25.        like this:
  26.  
  27.         {
  28.         loop:
  29.             // do something that creates a temporary here
  30.             if(cond) goto loop;
  31.         }
  32.  
  33.        If you'really serious about destroying temporaries at end of
  34.        block, that means you need a mechanism for allocating potentially
  35.        uncbounded stack space and keeping track of all the destructors
  36.        so as to be able to undo them all at the end.  This can be a
  37.        real pain, especially if you are trying to compile to C.
  38.  
  39.     2. Even if you don't want to handle things like the above, you
  40.        would still need flags that correspond to temporaries created
  41.        conditionally, particular in ?: expressions.  These flags
  42.        can potentially impose significant overhead even on people who
  43.        don't care about when the temporaries are destroyed.
  44.  
  45.     3. I have heard comments from users who really want temporaries
  46.        cleaned up early if possible.  Typically they are using linear
  47.        algrbra packages and write things like this:
  48.  
  49.         Matrix D = A * B * C;
  50.        
  51.        and do not want the intermediate result A * B to hang around
  52.        until the end of the block.  Of course they can't enclose this
  53.        in braces because then that would tear down D as well.  Moreover,
  54.  
  55.         Matrix D;
  56.         {
  57.             D = A * B * C;
  58.         }
  59.  
  60.        in addition to being ungainly, substitutes assignment for
  61.        initialization.  This can be significantly slower in some
  62.        implementations.
  63.  
  64. Destruction at end of block is far from a hopeless approach, but I
  65. think it loses on balance.  Indeed, there's something to be said for
  66. almost every approach, which is why this is a knotty problem.
  67. -- 
  68.                 --Andrew Koenig
  69.                   ark@europa.att.com
  70.