Topic: Pointers and garbage collection


Author: harrison@sp1.csrd.uiuc.edu (Luddy Harrison)
Date: Tue, 18 May 93 12:13:13 GMT
Raw View
fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

> FILE *f = fopen("/tmp/x","wb");
> Foo *p = new Foo;
> fwrite(&p, sizeof p, 1, f);
> p = 0;
> ...
> // assume that a garbage collection occurs here
> ...
> rewind(f);
> read(&p, sizeof p, 1, f);
> p->foo(); // *p had better still be there

>Now unless I am mistaken, this is legal C++ according to the current
>definition of the language.  But requiring this sort of code to work
>would make even conservative garbage collection impossible.
>Thus to make conservative garbage collection possible in a standard
>conforming implementation would require changing the standard to
>ensure that the above sort of code is illegal.

>I think that making such a change would be a good idea, but I wish that
>GC advocates would stop pretending that it doesn't require any changes
>to the C++ standard, or that it doesn't require the corresponding changes
>to C++ semantics.

I cannot agree that to forbid such constructs
is a good idea.  There are a number of programming languages already that
provide garbage collection; by contrast, how many programming languages
provide the low-level access that is required by the example above?  It
may be that such code is rare, but to make it impossible will change the
character of C++ altogether, in a way that would make it fundamentally
incompatible with C.  In a word, C++ would no longer be appropriate
for writing low-level, system software.  This would be a great mistake,
in my estimation.

I understand that attraction of garbage collection, but to elevate its
importance above that of the low-level semantics of the language should
not be done lightly.  Remember that some C++ programmers write
device drivers, others write Scheme interpreters (that provide their
own garbage collection!), others write real-time control software, others
write numerical libraries for supercomputers, and so on.  To many of
these programmers, garbage collection would be a positive nuisance; to
go farther, and alter the language semantics in a way that would
outlaw their use of it, is simply a bad decision.

On a related note, there seems to be much confusion about the distinction
between "implementation-defined" and "undefined".  An implementation-defined
feature is one whose behavior varies from implementation to implementation.
An example is the algorithm used to search for #include files.  It does
not at all follow that because the inclusion search is implementation-defined,
that it is sensible, for example, for an implementation to look for
#include files in a random directory, or to use a different algorithm every
time the compiler is invoked.  The same is true for the semantics of
pointers and pointer casting; they are implementation-defined, but certainly
they are not intended to be given a useless semantics; they are as important
to many applications as #inlude is, or as storage management is, for that
matter.

If you are reading this note in an editor running on a Unix machine, then
you are probably making use of five pieces of software that depend
upon the (implementation-dependent) semantics of pointer casting.

-Luddy Harrison (harrison@csrd.uiuc.edu)





Author: boehm@parc.xerox.com (Hans Boehm)
Date: 18 May 93 19:31:09 GMT
Raw View
harrison@sp1.csrd.uiuc.edu (Luddy Harrison) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>> FILE *f = fopen("/tmp/x","wb");
>> Foo *p = new Foo;
>> fwrite(&p, sizeof p, 1, f);
>> p = 0;
>> ...
>> // assume that a garbage collection occurs here
>> ...
>> rewind(f);
>> read(&p, sizeof p, 1, f);
>> p->foo(); // *p had better still be there

>>Now unless I am mistaken, this is legal C++ according to the current
>>definition of the language.  But requiring this sort of code to work
>>would make even conservative garbage collection impossible.
>>Thus to make conservative garbage collection possible in a standard
>>conforming implementation would require changing the standard to
>>ensure that the above sort of code is illegal...

>...  It
>may be that such code is rare, but to make it impossible will change the
>character of C++ altogether, in a way that would make it fundamentally
>incompatible with C.  In a word, C++ would no longer be appropriate
>for writing low-level, system software.  This would be a great mistake,
>in my estimation.

As has been pointed out before, all of the proposals that I have
seen for adding garbage collection to C++ would allow code like
the above to continue to function.  The Ellis-Delefs proposal would
leave *p in non-collected storage.  Even if you replaced new with
an allocator that garbage collected, and thus put *p
in collected storage, it wouldn't be hard to have fwrite rememember
pointers that had been written out.  If the collector copied objects,
fwrite and fread would have to maintain the mapping.  And nobody
is arguing for a proposal that requires every application to be
garbage collected.

Other constructs, namely memcpy and casts to integers seem more
controversial, in that it's less clear (at least to me)
whether they are already implementation-defined, and they seem to have
a more profound effect.  (They only affect the detailed statement
of the Ellis-Delefs proposal.  This matters more if you want to provide
garbage collection as a link-time option without changing the language
syntax.  The Ellis-Detlefs proposal argues convincingly that this is
not ideal.)

It's true that if you want garbage collection, you could use languages
such as Scheme or ML.   And many times you should.  But in many cases that's
not practical, both for technical reasons (it may be hard to call the
libraries you need, there may not be a suitable implementation) and for other
reasons (everybody needs to know C and C++ anyway, and it takes more
training/maintenance etc. to deal with multiple languages).


Hans-J. Boehm
(boehm@parc.xerox.com)




Author: jimad@microsoft.com (Jim Adcock)
Date: 19 May 93 17:10:29 GMT
Raw View
In article <1993May18.121313.16193@csrd.uiuc.edu> harrison@sp1.csrd.uiuc.edu (Luddy Harrison) writes:
|>I think that making such a change would be a good idea, but I wish that
|>GC advocates would stop pretending that it doesn't require any changes
|>to the C++ standard, or that it doesn't require the corresponding changes
|>to C++ semantics.
|
|I cannot agree that to forbid such constructs
|is a good idea.  There are a number of programming languages already that
|provide garbage collection; by contrast, how many programming languages
|provide the low-level access that is required by the example above?  It
|may be that such code is rare, but to make it impossible will change the
|character of C++ altogether, in a way that would make it fundamentally
|incompatible with C.  In a word, C++ would no longer be appropriate
|for writing low-level, system software.  This would be a great mistake,
|in my estimation.
|
|I understand that attraction of garbage collection, but to elevate its
|importance above that of the low-level semantics of the language should
|not be done lightly....

Again I suggest that people who are interesting in the subject of C++
and GC please read the Modula-3 manuals.  Modula-3 is equally applicable
to low level work as C++.  Modula-3 equally has requirements to maintain
compatibility with existing Modula and Modula-2 code.  Yet Modula-3 has
Garbage Collection, and Modula-3 programmers don't have this controversy
over GC or not GC.  How can this be?  Read the Modula-3 manuals and
find out!  The basic approach is to give the programmer *choice*
on what to apply GC.  This in turn requires a little bit of language support,
which is WHY we're asking consideration of GC in the language.

If someone feels they have a better solution to the GC issue in C++
than the Modula-3 authors already took in Modula-3, then let's here
your comparison of the two techniques.  Otherwise let's not argue
inferior approaches and/or problems simply for the sake of "not
invented here."

Again the question is not GC or no GC, the question is whether C++
gives programmers the *choice* to use GC or not GC, or whether C++
*denies* programmers that choice.  Given the pervasiveness of GC in
other OOPLs, I believe it would be shortsighted and ultimately
limiting to deny the GC option to C++ programmers.