NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/13033

Internet Message Format | 1992-08-29 | 2.5 KB

Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ulysses!allegra!alice!ark
From: [e-mail] (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Date: 28 Aug 92 15:40:39 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] ()
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 47

In article <[e-mail]> [e-mail] (Dave Gillespie) writes:

> Your description is more dramatic than clear :-), but it brings to
> mind an example where garbage collection could be troublesome in C++.
> Is this what you were thinking of?

>    class D *orphanedThing;
>    class C {
>      D *thing;
>      ~C() { orphanedThing = thing; }
>    };

That is indeed a troublesome case for GC in C++.

I think the right answer, at least for most practical purposes, is to
say that the purpose of garbage collection is to simulate unbounded
memory.  Once an object has become garbage, there is no way to tell
whether that memory is still in use, so the implementation should be
allowed to reclaim it without explicitly destroying the object.
As a programmer, you shouldn't care; you have no way of finding out that
it happened.

Now, of course, there is a problem here: people may well want garbage
collection to be not quite so transparent.  Suppose, for example, that
an object holds some kind of resource, such as a file descriptor.  It
would be nice to release that resource, too, after the object is no
longer visible.

However, I don't think it's right to do this in the garbage collector:
if you have enough physical memory, GC may not occur for a long time.
Imagine, for example, a window system that relies on GC to remove windows
whose associated process has died.  You want those windows to go away
*now*, not after an indeterminate interval.

I have seen one compromise position, though, that might conceivably
be useful for some of these problems: the notion of a `weak pointer.'
A weak pointer points at an object as long as the object is still
around; when the only pointers to an object are weak pointers, the
object is deleted and all the weak pointers are set to zero.  You can
then test the weak pointer at some future time and see that the object
has vanished without the kinds of circularites implied by the earler
example.

Would weak pointers be useful?  I'm still not convinced one way or the other.
--
                --Andrew Koenig
                  [e-mail]