Newsgroups: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Message-ID: <hbakerD04xoJ.FMz@netcom.com>
Organization: nil
References: <3be0mh$1p7@gamma.ois.com> <hbakerD034p9.Hq8@netcom.com> <3bjh1g$9ua@gamma.ois.com>
Date: Thu, 1 Dec 1994 14:02:42 GMT
Lines: 19
Xref: glinda.oz.cs.cmu.edu comp.lang.c:118700 comp.lang.c++:101201 comp.lang.lisp:15888

In article <3bjh1g$9ua@gamma.ois.com> beckwb@ois.com (R. William Beckwith) writes:
>Henry G. Baker (hbaker@netcom.com) wrote:
>
>: I think that I understand your 'weak reference' scheme.  However,
>: how does one know when tracing a 'weak reference' whether the target
>: still exists, or has been recycled for another purpose.
>
>I have played with two approachs.  The first is to set the weak
>reference object's pointer to null when the object is reclaimed.

Uh....  How do you propose to do this?  How do you propose to find all
of these 'weak references' (improper terminology: 'deferred increment'
is better)?

Henry Baker
Read (192.100.81.1) ftp.netcom.com:/pub/hb/hbaker/README for ftp-able papers.
WWW archive: ftp://ftp.netcom.com/pub/hb/hbaker/home.html
************* Note change of address ^^^        ^^^^

