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

Internet Message Format | 1992-08-17 | 4.5 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: 18 Aug 92 06:17:25 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: Synaptics, Inc., San Jose, CA
Lines: 84
In-reply-to: [e-mail]'s message of 16 Aug 92 07:58:04 GMT

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

> The real problem with GC is that it is based on a particular model of
> how a programming language represents something.  That model states
> that the _value_ of something is all that matters; once the value
> disappears, the identity means nothing.  On the other hand, C++, with
> defined lifetimes for objects, declares that the object identity is
> part of the model of computation.

Well, *can be* part of the model of computation.

> To put it differently, when does the destructor for a GC'd object get
> called?

Answer number one:  When it's collected, of course!

Answer number two:  When you have GC, many of the reasons for using
destructors go away.  There will always be classes that really need
to do something active when they're destroyed, but the majority of
the destructors I have seen do nothing more than delete temporary
storage, adjust reference counts, and call other destructors, all
of which can be made unnecessary with GC.

> What happens if the GC'd object's destructor makes a call that
> has an effect outside the system?  In other words, what happens to
> relationships between the objects in the system and the world outside?

If this matters, don't use GC for that object.  Delete it yourself.
(I would certainly agree that "delete" needs to be retained in the
language, no matter what kind GC is also provided.)

> A great deal of a program's information is stored in the relationships
> between things, and not just in their values.  A GC'able language has
> a certain semantic restriction: you will never use the actual object
> (i.e. object-in-memory as C and C++ define the word) identity to represent
> something.  If you have a reference to another object, it is because you
> are interested in the value stored there, not in the object identity
> itself.  Once the value is no longer accessible, the object identity is
> worthless.

I'm not sure I see where the "restriction" comes in.  We're not talking
about taking anything out of C++; a GC proposal is not going to restrict
anybody about how they use C++.  It will simply give them more options
in how they manage their memory.

Suppose you have an existing C++ program.  Suppose there is an object
in that program's memory that has been allocated and which no longer
has any references to it of any sort, and which has not been deleted
explicitly.  Most people would consider that a bug; a conscientious
program ought to delete everything it allocates as a matter of
principle; but your program is not planning on deleting the object
because it no longer has any references to it.  Is there really so
much harm in allowing the C++ runtime system to delete the object in
that circumstance?  If you left the object dangling and it had a
destructor that had a noticeable effect on the rest of the program,
you almost certainly had a bug anyhow.

> C++ doesn't make this assumption.  Some data structures that are written
> in C++ may, and GC may be suitable for those data structures.  But the
> suitability of those data structures to GC shouldn't be mistaken for
> the suitability of C++ for GC.

I've written plenty of programs that didn't use floats at all, so are
floats not suitable for C++?

In fact, I've written programs that didn't use "new" at all.  I'm still
glad to have it in the language, though, because I've written plenty
of other programs that did.

Let's try a less pedantic example:  C++ breaks down around the edges
on the issue of allocating arrays of class objects (it doesn't allow
"operator new" to be overloaded on them, for example), but it still
provides the feature because it's useful to many C++ programmers.

C++ is used for all sorts of programs, and all sorts of programming
styles.  If there is any one overriding philosophy I see in C++, it's
to give the programmer the tools to allow the best solution for the
problem at hand.

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