home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13019 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.7 KB
  1. Path: sparky!uunet!ogicse!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <TMB.92Aug28190933@arolla.idiap.ch>
  6. Date: 28 Aug 92 23:09:33 GMT
  7. Article-I.D.: arolla.TMB.92Aug28190933
  8. References: <23466@alice.att.com> <3920@starlab.UUCP> <23487@alice.att.com>
  9.     <1992Aug25.182538.9117@microsoft.com>
  10. Sender: news@ai.mit.edu
  11. Reply-To: tmb@idiap.ch
  12. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  13.     Perceptive)
  14. Lines: 66
  15. In-reply-to: jimad@microsoft.com's message of 25 Aug 92 18:25:38 GMT
  16.  
  17. In article <1992Aug25.182538.9117@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  18.  
  19.    I suggest that something like the following set of rules would in practice
  20.    allow compiler implementations such that all existing conforming
  21.    compiler/program pairs could continue to work:
  22.  
  23.    Rules in order of precedence:
  24.  
  25.    1) Lifetimes of unnamed temporaries never exceed their surrounding blocks,
  26.      including the implied rewriting blocks of loops and conditionals.
  27.  
  28.    2) Named temporaries live to the end of their name's surrounding block.
  29.  
  30.    3) Temporaries must live until after their last access or end of block --
  31.    whichever comes first.
  32.  
  33.    4) Compilers are allowed to destroy temporaries anytime in any order after
  34.    their last access.
  35.  
  36.    [...]
  37.  
  38.    Niave implementations can simply wait to the end of block [where "block"
  39.    includes the implied rewriting rules of loops and conditions].  Optimizing
  40.    compilers are free to reclaim objects as soon as they are done being used.
  41.    In some cases, this may be very hard for optimizing compilers to determine --
  42.    in which case they are free to fall back on the naive scheme.  In practice,
  43.    in many cases an optimizing compiler can simply determine last access,
  44.    and can optimize lifetimes well.
  45.  
  46. If any function that is not visible to the compiler ever gets its
  47. hands on the temporary, the temporary can't be deallocated at the end
  48. of the block, since that function might have put a pointer to the
  49. temporary somewhere. That means that the _only_ cases in which a
  50. compiler might be able to optimize temporaries are cases in which all
  51. the functions involving the temporaries are defined in the same
  52. compilation unit, and of those cases, it will still not be able to
  53. optimize most.
  54.  
  55.    Under these rules the only difference between named objects and unnamed
  56.    objects is the destruction of named objects *must* occur at end of block,
  57.    whereas for unnamed objects destruction can occur earlier.
  58.  
  59. Under your rules, for all practical purposes, there is no difference
  60. between named objects and unnamed objects. You might as well simply
  61. clearly state that unnamed temporaries live until the end of the
  62. block. That way, nobody would have any illusions.
  63.  
  64.    The above rules shift the burden of temporaries to optimizing compilers.
  65.  
  66. No, it shifts the burden of temporaries to optimizing users: it means
  67. that the user, for all practical purposes, could not use large
  68. temporaries anymore, since he could pretty much expect that they all
  69. accumulate until the end of the block.
  70.  
  71. I don't understand all this hoopla about temporaries. Yes, I myself
  72. strongly dislike the fact that automatic variables and temporary
  73. objects have dynamic extent in C++ (i.e., that pointers to them become
  74. invalid).  But that problem is not going to be fixed by making those
  75. objects live just a little longer. In fact, for all practical
  76. purposes, the problem simply isn't fixable within C++. At best, you
  77. can avoid it by using special coding conventions, by using GC and heap
  78. allocated objects, or by using a different language. I have used all
  79. three methods, depending on the particular constraints on my current
  80. project.
  81.  
  82.                     Thomas.
  83.