In article <1992Aug6.014619.2111@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>GC classes cannot be allocated on the stack or statically,
>so when one is, it is silently converted to a GC pointer
>to an object.

>Pointers to GC class objects will be GC pointers.
>GC pointers are like classes, they have built in destructors and
>constructors so they can't just disappear.

I think this is a neverending loop. If pointers to GC class objects will be
GC pointers too, they will be silently converted to a GC pointer (which is
a pointer to a GC class) and must be silently converted to a GC ...

=> GC class objects must be allocatable on the stack - but the compiler
must recocnize this.

Adios
--
Michael Hoennig                                  FAX:   +49 40 23 646 550
StarDivision GmbH                                Phone: +49 40 23 646 500
Sachsenfeld 4                                    uucp: ...!unido!starlab!mi
D-W-2000 Hamburg 1                               domain: mi@starlab.uucp

>I like the idea of GC so much that I a driven to consider
>how it might be implemented in C++.

Lots of people have already thought about this.  There's a running argument
currently going on in comp.compilers about GC strategies for C and C++.  Take
a look.

--
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
Re-elect Vice President Potatoe-Head !

 I like the idea of GC so much that I a driven to consider
how it might be implemented in C++. Here is an outline of an idea.

 To implement GC, the collector must know where all the
collectable objects are, and where all the pointers (or references)
to those objects are.

 GC class X { .....

GC classes cannot be allocated on the stack or statically,
so when one is, it is silently converted to a GC pointer
to an object.

Pointers to GC class objects will be GC pointers.
GC pointers are like classes, they have built in destructors and
constructors so they can't just disappear.

Operator delete CAN be applied to GC pointers, however the object
is not deleted if there are still references other references
to it, the object IS deleted right then and there if there are
no other references. It is NOT necessary to delete GC objects though.

The garbage collector gets exercised by calling specific functions,
including, for example delete, and of course, at program termination.
It can also be exercised when creating new GC objects.

The GC system as proposed would not be safe unless certain contraints
were met. For example if GC pointers are allowed in non-GC objects,
the user had better delete the pointer on the object destruction.

The use of GC objects for temporaries should be encouraged, as
it solves the nasty problem of the lifetime of temporaries.

Since the use of GC would be at programmer discretion,
no overhead is implied unless GC is actually used.

I would like to know:

 a) What idiom is equivalent to using GC.
    Which cases are not supported by any idiom?

 b) Could that idiom be built into the language to advantage?

 c) What are the 'best' rules for allowing GC objects and pointers
 to interact with ordinary C++ objects and pointers?
 (And references!)

 d) How could GC be combined with notions of persistence to
 implement OODBMS :-) more effectively

GC solves MAJOR  problems. Using it consistently, for example,
assures us that pointers cannot dangle, nor memory leaks exist.

Could I have some comments please: What would it take to
implement optional GC in C++? How safe would it be?
Could it be made totally secure, and if so what is the
penalty in flexibility and compatibility?


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------

   GC solves MAJOR  problems. Using it consistently, for example,
   assures us that pointers cannot dangle, nor memory leaks exist.

   Could I have some comments please: What would it take to
   implement optional GC in C++?

You can't do it "by hand", since the garbage collector must be able to
look at stack frames. You can barely do it if all references to the
objects are via "smart pointer classes" (see Coplien).

Anything you kludge up by hand like this is going to be a lot less
efficient than a real garbage collector (in fact, in my experience,
manual storage management is almost invariably less efficient than
automatic storage management).

You can also use a conservative garbage collector (you can FTP one
from XeroxParc). This sort of works, but is not generally portable.

   How safe would it be?

Real GC wouldn't be safe if "delete" actually returned storage to the
system.

Having tried all these different approaches, I have come to the
conclusion that it's not worth the effort trying to emulate GC in C++.
For those occasions where I need real GC, I use a different language.
Fortunately, most of my work doesn't involve circular structures, so
that I can live with the usual slow but simple reference counting or
copying techniques.

    Thomas.

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

> I like the idea of GC so much that I a driven to consider
>how it might be implemented in C++. Here is an outline of an idea.

Sounds like a great idea!
You might like to take a look at the collector on gatekeeper.dec.com,
in pub/DEC/CCgc. This is (I think) a conservative collector that
scans the run-time stack, so it is rather different from your
proposal (i.e. not programmer-controlled). I haven't used it,
so can't comment on its usability/usefulness.

(There is also a collector for C in pub/DEC/Cgc).

Regards

John Reekie