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!gatech!newsxfer.itd.umich.edu!caen!msunews!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Message-ID: <9434718.3597@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
References: <D03Iwn.Jn5@research.att.com> <3boujh$o0c@news.parc.xerox.com> 	<JYL.94Dec8204808@frstprsn.eng.sun.com> 	<D0JzqA.nB@maunakea.Data-IO.COM> <JYL.94Dec9160456@yael.eng.sun.com>
Date: Tue, 13 Dec 1994 07:14:22 GMT
Lines: 25
Xref: glinda.oz.cs.cmu.edu comp.lang.c:120341 comp.lang.c++:102802 comp.lang.lisp:16016

jyl@yael.eng.sun.com (Jacob Levy) writes:

>You've just proven my point that GC tends to hide the problems instead of
>allowing a user to correct them. GC didn't remove your bugs, instead you
>were able to hide them so as to be able to deliver your product.

GC doesn't hide bugs, it removes them (by making them non-bugs).
Your comments show a lack of understanding of the fundamental purpose of GC.

A bug is when some code does not do what it is supposed to do.  With
garbage collection, it is supposed to be the garbage collectors
responsibility to collect garbage.  With GC, it is *not* the
responsibility of the code to manually deallocate storage.  Hence it is
not the case that code which does not do so is buggy.

>Speaking
>as a purist, without regard to product deadlines, I consider a program that
>leaks memory as incorrect, even if the bugs don't manifest themselves in
>unbounded heap growth.

But programs using garbage collection *don't* leak memory.
That's the whole point!

-- 
Fergus Henderson - fjh@munta.cs.mu.oz.au
