home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!uwm.edu!linac!att!att!allegra!alice!ark
- From: ark@alice.att.com (Andrew Koenig)
- Newsgroups: comp.lang.c++
- Subject: Re: Garbage Collection for C++
- Message-ID: <23551@alice.att.com>
- Date: 26 Aug 92 14:45:40 GMT
- 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>
- Reply-To: ark@alice.UUCP ()
- Organization: AT&T Bell Laboratories, Murray Hill NJ
- Lines: 35
-
- In article <1992Aug25.182943.9266@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
-
- > These same thoughts could be equally applied to the lifetime of temporaries,
- > leading to the conclusion that the lifetimes of temporaries ought to be
- > the same as for named objects.
-
- I thought so too (with the restriction that temporaries created in conditional
- contexts be destroyed in those contexts) until I noticed the following:
-
- {
- statement1;
- if (condition) goto label;
- statement2;
- label: statement3;
- }
-
- If statement2 generates a temporary, it is no longer possible to destroy the
- temporary after statement3 without having to remember whether or not the
- goto was executed. That leaves three possibilities, all unpalatable:
-
- 1. Force the implementation to store flags to keep track of control
- flow in cases like this, or
-
- 2. Say that all temporaries are destroyed at every label, or
-
- 3. Prohibit a goto from crossing a statement that generates a temporary.
-
- Alternative (1) is a real pain for the implementor and in come cases can
- incur significant run-time overhead. Alternative (3) would break lots of
- existing code. That leaves (2). It turns out, though, that a clear formulation
- of the intent of (2) is quite difficult in the presence of break, continue,
- and return statements. Maybe someone out there can find one?
- --
- --Andrew Koenig
- ark@europa.att.com
-