Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!duke!bet
From: bet@orion.mc.duke.edu (Bennett Todd)
Newsgroups: comp.lang.c++
Subject: GC (was Re: Eiffel vs. C++ (vs Smalltalk))
Message-ID: <14739@duke.cs.duke.edu>
Date: 13 Jun 89 22:47:34 GMT
References: <5316@tekgvs.LABS.TEK.COM> <77300030@p.cs.uiuc.edu>
Sender: news@duke.cs.duke.edu
Reply-To: bet@orion.mc.duke.edu (Bennett Todd)
Organization: Diagnostic Physics, Raddiology, DUMC
Lines: 48
In-reply-to: johnson@p.cs.uiuc.edu

In article <77300030@p.cs.uiuc.edu>, johnson@p.cs writes:
>[...]
>                                      However, the main reason for a garbage
>collector in C++ would be to catch "space leaks", so it would not have to
>be called very often.

I think this observation is crucial to appreciating the gap between
those of you who like garbage-collecting environments and those of us
who don't (what, me biased?:-). Part of the job I take on in program
design and implementation is closely tracking allocation of crucial
resources, including memory. I view a memory leak as a bug; when I write
something big enough that I am not absolutely positive I didn't miss any
potential leaks, I always drive it for a long while with a steady load
of work which should settle down to a steady state of memory
consumption, then set back and examine its memory use via top(1) (or
ps(1) or whatever tool is the least unpleasant to use for the job:-).
I'm not sure where the damage was done to my brain; I guess it is
probably because I got taught techniques that enable me to write
extremely large, complex applications while tracking the memory
consumption myself, before I ever got exposed to a garbage-collecting
environment. By then I didn't feel any strong need to abandon these
techniques, since they don't seem cumbersome to me.

In particular I remember fondly a really bizarre package I wrote, more
as an exercise in "can I do this?" than for practical application. As I
recall, I wanted to write the closed form roots of polynomial expression
in C, so I wrote a complex library. I wanted to be able to write
composed expressions, and not have the implicit intermediates get
dropped on the floor, e.g.

	result = plus(complex(1.0,0.0),complex(0.0,1.0));

Necessarily the two calls to the constructor complex() will produce two
intermediates; I decided to mandate that all arithmetic operators would
destroy their arguments. I called this convention "parameter passing by
call and destroy" and it always struck me as pleasantly perverse. These
days, with structs being treated to call-by-value and properly supported
assignment, and struct return generating suitably allocated anonymous
copies, the above shenanighans aren't needed any more (and C++ offers,
at last, the ability to make a complex type both as convenient to use
and as efficient as if it were defined as an arithmetic primitive in the
language -- death to Fortran!:-). Nonetheless, it wouldn't appeal to me
to create a package which goes about allocating memory, and dropping it
on the floor, on the assumption that a garbage collector will pick up
the pieces after me.

-Bennett
bet@orion.mc.duke.edu