home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12894 < prev    next >
Encoding:
Text File  |  1992-08-25  |  2.7 KB  |  74 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <1992Aug25.182538.9117@microsoft.com>
  6. Date: 25 Aug 92 18:25:38 GMT
  7. Organization: Microsoft Corporation
  8. References: <23466@alice.att.com> <3920@starlab.UUCP> <23487@alice.att.com>
  9. Keywords: temporaries,destruction,statements,block,early
  10. Lines: 62
  11.  
  12. In article <23487@alice.att.com> ark@alice.UUCP () writes:
  13. |    1. strict end of block destruction creates problems for programs
  14. |       like this:
  15. |
  16. |        {
  17. |        loop:
  18. |            // do something that creates a temporary here
  19. |            if(cond) goto loop;
  20. |        }
  21. |
  22. |       If you'really serious about destroying temporaries at end of
  23. |       block, that means you need a mechanism for allocating potentially
  24. |       uncbounded stack space and keeping track of all the destructors
  25. |       so as to be able to undo them all at the end.  This can be a
  26. |       real pain, especially if you are trying to compile to C.
  27.  
  28. I don't think people mean to imply that lifetimes of unnamed temporaries ought
  29. to live longer than an equivalent named temporaries.  Both should be subject
  30. to the same "implied block" rewriting rules in the face of loops or 
  31. conditional expressions:
  32.  
  33.         {
  34.         loop:
  35.             { // implied
  36.             // do something that creates a temporary here
  37.             if(cond) goto loop;
  38.             } // implied
  39.         }
  40.  
  41.  
  42. I suggest that something like the following set of rules would in practice
  43. allow compiler implementations such that all existing conforming
  44. compiler/program pairs could continue to work:
  45.  
  46. Rules in order of precedence:
  47.  
  48. 1) Lifetimes of unnamed temporaries never exceed their surrounding blocks,
  49.   including the implied rewriting blocks of loops and conditionals.
  50.  
  51. 2) Named temporaries live to the end of their name's surrounding block.
  52.  
  53. 3) Temporaries must live until after their last access or end of block --
  54. whichever comes first.
  55.  
  56. 4) Compilers are allowed to destroy temporaries anytime in any order after
  57. their last access.
  58.  
  59. ====
  60.  
  61. The above rules shift the burden of temporaries to optimizing compilers.
  62. Niave implementations can simply wait to the end of block [where "block"
  63. includes the implied rewriting rules of loops and conditions].  Optimizing
  64. compilers are free to reclaim objects as soon as they are done being used.
  65. In some cases, this may be very hard for optimizing compilers to determine --
  66. in which case they are free to fall back on the naive scheme.  In practice,
  67. in many cases an optimizing compiler can simply determine last access,
  68. and can optimize lifetimes well.
  69.  
  70. Under these rules the only difference between named objects and unnamed
  71. objects is the destruction of named objects *must* occur at end of block,
  72. whereas for unnamed objects destruction can occur earlier.
  73.  
  74.