From: boehm@parc.xerox.com (Hans Boehm)
Newsgroups: comp.lang.c++
Subject: Re: C++ Critique (3 of 4) (long)
Date: 16 Apr 92 17:13:47 GMT
Article-I.D.: siria.boehm.703444427
Organization: Xerox PARC

ian@syacus.acus.oz.au (Ian Joyner) writes:

>nagle@netcom.com (John Nagle) writes:

>>       Garbage collection is not a real solution for a language with
>>destructors.  It's adequate for getting memory back, but if important
>>actions like the release of locks and closing of windows, files, and 
>>other objects take place at deallocation, deferred deallocation can
>>produce very strange results.  Reference counts combined with
>>uncontrolled pointers result in unreleasable circular lists, of course.
>>This remains a major unsolved problem with pointer-based languages.

>I don't think that garbage collection and destructors go together. An 
>object is garbage collected when it has already left the universe.
>Calling a destructor at this time gives the object an opportunity to
>link itself back into the universe. Maybe this would be a new kind of
>'bug' (a misleading term in itself) that could be termed a 'ghost' :-)
>Maybe the solution is to limit a destructor in a GC scheme to very
>limited operations. Of course, if you don't have explicit 'delete',
>then where you want to close a file by deleting the file object,
>you could instead explicitly call close on the file. Any further
>operations on the file would indicate that not all references have
>been lost, and should cause an error in the file object. I don't
>think there is anything particularly magic about destructors that
>cannot be achieved in other ways. But it is nice to think that
>certain things will be cleaned up in an object when it goes out of
>scope. But then the difficulty in programming with dynamic entities
>is determining exactly when things have gone out of scope, and are
>no longer referenced. As software becomes more complex, I can only
>see this problem getting worse.

I'm not convinced that there's a real open problem here.  My impression
is that C++ destructors are used primarily for two, in my opinion
very distinct, purposes:  (Since I am not much of a C++ programmer,
please correct me if I'm wrong):

1. To perform necessaary clean up actions when a scope is left.  These
are actions that must be performed to ensure continued correct functioning
of the program, even on a hypothetical machine with infinite resources.
The canonical example is releasing a lock.  This corresponds to the
TRY ... FINALLY ... construct in Modula-3.

2. To reclaim inaccessible resources.  (The caononical examples here
are inaccessible memory and inaccessible file descriptors that should
be closed.)

I claim that the first use has a lot to do with exception handling,
and essentially nothing to do with garbage collection.  This facility
needs to exits in some form, whether or not there's a garbage collector.

The second use can be handled by a garbage collector.  It's primary
job is to reclaim memory.  But it's also easy to enqueue inaccessible
objects that have been suitably registered for further processing.
Both Cedar and PARCPlace SmallTalk have facilities to do this.  There
is not even a fundamental problem with "resurrecting" objects that
are processed in this way.  (There are tricky issues associated with
the order in which inaccessible objects are processed.  But these
are much more obscure than the level of this discussion.)

There is no problem with handling file descriptors in this way;  if you run out of file descriptors, you force a garbage collection.

Hans
(boehm@parc.xerox.com)

Standard disclaimer ...
Newsgroups: comp.lang.c++