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!Germany.EU.net!EU.net!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: Reference Counting (was Searching Method for Incremental Garbage
Message-ID: <RH2ewc1w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <3b7s28$954@scipio.cyberstore.ca>
Date: Sat, 26 Nov 1994 20:59:26 GMT
Lines: 28
Xref: glinda.oz.cs.cmu.edu comp.lang.c:117992 comp.lang.c++:100469 comp.lang.lisp:15824

kevinw@whistler.com (Kevin Warne) writes:

> Contrast this to existing C++ practice...  The programmer (the gov't in 
> this example) has to set out a global allocation policy and manually 
> trace the lifespan of each object...  If a class is reused in a 
> second application then this lifespan analysis has to be redone 
> and allocations retraced.
> 

Howdy,
        Well put. I think it might be important here on comp.lang.c++
to emphasize that GC is not just (1) lazy programming or even
(2) useful for implementing certain algorithms. (Both might be true
for specific cases).  
        GC, i.e. "automatic storage management", is a key player 
in how easily system modularization and code reuse is achieved.  In
my experience at various run-o-the-mill coding shops, modularization
and reuse has often broken down over issues of resource management.
For these non-rocket scientists, GC would have been a god send and
would have helped them leap the barrier between OO hype and practice.
        OTOH, I do not think C/C++ should be retrofitted with
GC - breaks the spirit of the langauges. Which leaves a burning
question.....

=============================================
Scott McLoughlin
Conscious Computing
=============================================
