NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12624

Internet Message Format | 1992-08-20 | 2.7 KB

Path: sparky!uunet!synaptx!synaptics.com!daveg
From: [e-mail] (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Date: 20 Aug 92 11:31:56 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: Synaptics, Inc., San Jose, CA
Lines: 49
In-reply-to: [e-mail]'s message of 19 Aug 92 18:02:52 GMT

In article <[e-mail]> [e-mail] writes:

>>   Is there really so much harm in allowing the C++ runtime
>>   system to delete the object in that circumstance?

> You've answered your own question in the negative.  If the destructor
> has an effect on the program's output, and it is accidentally called
> by the GC instead of by its proper deletion, the program's output will
> depend on the exact properties of the GC system and the exact sequencing
> of internal states of the program and of the program's runtime internals'
> states.  It might work correctly by accident in testing, and fail
> disastrously in service.

Sorry, I didn't make myself clear.  I realize that allowing GC to call
a destructor would add one more case where destructors with side effects
could surprise the C++ programmer.  My question was, is that potential
for surprise enough to kill the idea of garbage collection in C++?

My answer is no, it just means C++ programmers who use garbage collection
have to be a little careful about what they put in their destructors.

> Allowing GC to operate destructors is not safe.

Only if "new" statements in existing programs create collectable objects.
If you have to do something special, like say "GCnew" (admittedly not the
most pleasing notation), then existing programs won't break, and the
chapter on garbage collection just has to include a caveat that if you
allocate an GC-able object with a destructor that has side effects, you'd
better watch out because you can't know when those side effects will
occur.

> Not allowing GC to operate destructors does not suit C++'s model of
> execution.

Agreed.  For example, an object giving access to a file wants to close
the file when it's collected.  A class might want to keep statistics
on how many instances of the class are currently allocated, etc.

> Think about it.

I did; as far as I can tell, the GC has to call destructors, and it's
acceptable for it to do so as long as it doesn't break existing code,
which can be done by introducing something like "GCnew".  Simple as that.

                                -- Dave
--
Dave Gillespie
  [e-mail], uunet!synaptx!daveg
  or: [e-mail]