Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!hockey.cis.ohio-state.edu!grichard From: grichard@hockey.cis.ohio-state.edu (Golden Richard) Newsgroups: comp.sw.components Subject: Re: Re: Garbage Collection & ADTs Message-ID: <62546@tut.cis.ohio-state.edu> Date: 25 Sep 89 18:20:44 GMT References: <900@scaup.cl.cam.ac.uk> <6530@hubcap.clemson.edu> <909@scaup.cl.cam.ac.uk> <62342@tut.cis.ohio-state.edu> <599@hsi86.hsi.UUCP> Sender: news@tut.cis.ohio-state.edu Reply-To: Golden RichardOrganization: Ohio State University Computer and Information Science Lines: 36 In article <599@hsi86.hsi.UUCP> wright@hsi.com (Gary Wright) writes: >In article <62342@tut.cis.ohio-state.edu> Golden Richard writes: >>In article <909@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: >>[pro-GC arguments deleted] > >Well, I have *never* encountered a situation that absolutely demanded using >a high level language. That is why I still do all my programming in >assembly. :-) > >If our criteria for deciding whether GC is better than explicit memory >management is based on absolutes, we will never come to a conclusion. > I never intended to sound as if I were daring someone to come up with an application which I couldn't handle with programmer-managed reclamation. The "absolutely demanded" phrase in my article was prompted by references to (unnamed) applications which supposedly require GC to ease the burden on the programmer. To rephrase my statement, I have never encountered an application where GC was necessarily preferable to programmer-managed reclamation. Furthermore, I can't imagine a properly designed application where storage management is so complicated that the usual techniques for programmer-managed storage reclamation aren't adequate. If the programmer can't define when a certain object can go poof, I suspect a serious lack of understanding of the problem at hand. -=- Golden Richard III OSU Department of Computer and Information Science grichard@cis.ohio-state.edu "I'm absolutely positive! ...or not."