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: <CzuxH4.7s2@world.std.com>
Reply-To: tob@world.std.com
Organization: BREnterprises
References: <3b5rjj$kg8@scipio.cyberstore.ca>
Date: Sat, 26 Nov 1994 04:22:16 GMT
X-Posted-By: My own casual posting program
Lines: 32
Xref: glinda.oz.cs.cmu.edu comp.lang.c:117922 comp.lang.c++:100396 comp.lang.lisp:15813

kevinw@whistler.com (Kevin Warne) writes:
> Unfortunately it won't be automatic.
>
> I think it's important to maintain a distinction between reference
> counting as accounting for explicit memory management and reference
> counting collectors as a form of automatic memory management.

OK. Actually I agree. Doing it without a lot of programmer effort, and
without introducing error opportunities is important. But so is opening
opportunities for efficiency.

Can what I describe be automated, or largely automated? I think at best
it could be largely automated, requiring a keyword or so and giving
compiler errors under conflicting conditions rather than runtime
failures. (Obviously only applicable to compiled languages)

Some optimizations can be automatic, like hoisting reference count
updates out of loops, or to the endpoints of an entire routine.

Others, like constraining a structure to only take references it can
own, would require communication from the programmer, though I'd love to
be shown wrong.

Perhaps the ideal would be to develop something with GC and then turn it
off when (if) you got around to fine-tuning it.

        Tom

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

