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!pipex!uunet!world!tob
From: tob@world.std.com (Tom O Breton)
Subject: Re: Reference Counting (was Searching Method for Incremental Garbage Collection)
Message-ID: <CzpJ7I.44D@world.std.com>
Reply-To: tob@world.std.com
Organization: BREnterprises
Date: Wed, 23 Nov 1994 06:26:06 GMT
X-Posted-By: My own casual posting program
Lines: 30
Xref: glinda.oz.cs.cmu.edu comp.lang.c:117566 comp.lang.c++:100019 comp.lang.lisp:15769

OK, I've been following this thread for a bit, and there are two
objections to reference counting that IMO aren't as strong as they
appear. I await other opinions of course.

0:      It orphans circular structures.

Well, if you do it naively, sure. But the way I've always handled such
memory is that there's a top structure (head pointer, usually) that owns
everything inside. Everything outside just borrows memory. Anything that
includes circular pointers is complex enough that it belongs in such an
encapsulation. Obviously you would count references to the head, not to
every member.

1:      It's slow, due to count update overhead.

Again, I get the impression that what one has in mind is a very naive
implementation. Say, one that "thrashes" every time there's a loop that
copies and destroys a pointer. I have even heard people who consider
that finding the length of a list in Lisp inc/dec's for _every step_!
The purpose of reference counting is to handle "sibling" deep pointers
where you don't know which one will get destroyed first. Reference
counting anything whose order of destruction you can predict at compile
time seems pointless.

        Tom

-- 
tob@world.std.com
TomBreton@delphi.com: Author of The Burning Tower

