home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12911 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  1.9 KB

  1. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!uwm.edu!linac!att!att!allegra!alice!ark
  2. From: ark@alice.att.com (Andrew Koenig)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <23551@alice.att.com>
  6. Date: 26 Aug 92 14:45:40 GMT
  7. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug17231725@synaptx.synaptics.com> <1992Aug19.180252.12942@mole-end.matawan.nj.us> <1992Aug25.182943.9266@microsoft.com>
  8. Reply-To: ark@alice.UUCP ()
  9. Organization: AT&T Bell Laboratories, Murray Hill NJ
  10. Lines: 35
  11.  
  12. In article <1992Aug25.182943.9266@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  13.  
  14. > These same thoughts could be equally applied to the lifetime of temporaries,
  15. > leading to the conclusion that the lifetimes of temporaries ought to be
  16. > the same as for named objects.
  17.  
  18. I thought so too (with the restriction that temporaries created in conditional
  19. contexts be destroyed in those contexts) until I noticed the following:
  20.  
  21.     {
  22.         statement1;
  23.         if (condition) goto label;
  24.         statement2;
  25.     label:    statement3;
  26.     }
  27.  
  28. If statement2 generates a temporary, it is no longer possible to destroy the
  29. temporary after statement3 without having to remember whether or not the
  30. goto was executed.  That leaves three possibilities, all unpalatable:
  31.  
  32.     1. Force the implementation to store flags to keep track of control
  33.        flow in cases like this, or
  34.  
  35.     2. Say that all temporaries are destroyed at every label, or
  36.  
  37.     3. Prohibit a goto from crossing a statement that generates a temporary.
  38.  
  39. Alternative (1) is a real pain for the implementor and in come cases can
  40. incur significant run-time overhead.  Alternative (3) would break lots of
  41. existing code.  That leaves (2).  It turns out, though, that a clear formulation
  42. of the intent of (2) is quite difficult in the presence of break, continue,
  43. and return statements.  Maybe someone out there can find one?
  44. -- 
  45.                 --Andrew Koenig
  46.                   ark@europa.att.com
  47.