Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!linus!agate!darkstar!terra!daniel
From: daniel@terra.ucsc.edu (Daniel Edelson)
Newsgroups: comp.lang.c++
Subject: Re: Smart pointers and stupid people (was: garbag
Message-ID: <11781@darkstar.ucsc.edu>
Date: 1 Feb 91 04:56:29 GMT
References: <lots...omitted>
Sender: usenet@darkstar.ucsc.edu
Reply-To: daniel@terra.ucsc.edu (Daniel Edelson)
Distribution: comp
Organization: University of California, Santa Cruz
Lines: 32

In article <70353@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
><argument for GC omitted>
>
>What the C++ community needs to be working on is ways to abstract-out 
>issues of GC and memory management from other aspects of class design,
>so that class libraries are not "hard-wired" to one or another memory
>management or GC schemes.

Yes but no. This is a wonderful idea for about 5 minutes. 

There is something very attractive about contemplating something 
like the following:

	CC -F -GCgenerations=2 -GCtype=copying cfront.C ...

	# Output is:
	/* <<AT&T C++ Translator 5.0 11/30/93>> */
	... C program omitted for brevity ...

That is, having a very flexible GC interface so that you really can 
plug in different algorithms. Unfortunately, this seems to be an
unrealistic ideal.

Copying GC probably imposes stricter stylistic requirements on the
programmer. Will programmer be willing to code to the stricter
standards unless they intend to use copying GC, even if it introduces
inefficiencies? 
Perhaps I'm wrong. Perhaps programmers will be willing to obey
stricter coding practices in order to bind late to the GC algorithm.

I doubt it but hope so.