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

Text File | 1992-08-13 | 4.3 KB | 114 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!mcsun!sunic!ericom!falcon!jonas
From: [e-mail] (Jonas Nygren)
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: falcon.ericsson.se
Reply-To: [e-mail]
Organization: Ericsson Telecom AB
References: <[e-mail]>
Date: Fri, 14 Aug 1992 10:12:26 GMT
Lines: 100

I do not know if this really went out. So I am reposting my own article.
/jonas

In article [e-mail], [e-mail] (Jonas Nygren) writes:
> In article [e-mail], [e-mail] (Dave Gillespie) writes:
> > > Any pointer to a GC class is a GC pointer, not an ordinary pointer.
> > > GC objects declared on the stack or in other GC classes or static
> > > are silently converted to GC references (GC pointers with
> > > reference semantics).
> >
> > I doubt this will be practical.  Partly because it would be too much
> > of a nuisance to use C++ if you had to keep track of GC vs. non-GC
> > pointers yourself, and partly because it would be impractical to
> > convert the libraries (as many people have said).
> >
>
> <gc discussion deleted>
>
> I am experimenting with a reference counting scheme where the ref-counter is
> placed in a class 'object', which every class that want to be shared must
> inherit. To work with multipel inheritance class 'object' should be declared
> public virtual. Class 'object' also has the information wether the object was
> dynamically allocated or not.
>
> On destruction of class 'object' a check is performed that there are no references
> to the object. If there are references we have dangling pointers and an assert/abort
> will be executed which will terminate the program.
>
> I use smart pointers based on templates to reference the instances which are
> derived from object. I call this smart-pointer class ref, in analogy with Simula.
>
> A small example could look like:
>
> class X : public virtual object {
>   public:
>     int f();
> };
>
> ref<X> rx = new X;
>
> rx->f();
> rx = 0; // causes the allocated X to be deleted
>
> ref's could also be used on auto/static allocated instances but these will never be
> deleted when there are no more outstanding references.
>
> I think this solution resembles the initial GC proposal for C++ very much,
> that's why I wrote this. What do you think of this solution? What are the
> drawbacks? The only drawback I have been able to identify is the general problem
> of circular references, which I see no solution for.
>
> > Here are some more issues that you would have to worry about with
> > a GC-ing C++:
> >
> > What if a signal handler fires during a GC?  (Maybe you just have
> > no choice but to have the system mask or disable signals during GC.)
>
> I can't see any problem with my solution.
>
> >
> > What if a GC occurs during a signal handler, and the interrupted
> > program was in the middle of, say, constructing or destructing an
> > object?  (I don't think you get bitten either way, but you'd want
> > to check this *really carefully*!)
> >
> > What if a pointer to a GC-able object is passed to foreign (non-C++)
> > code, which stashes it somewhere the C++ collector doesn't know to
> > look?  (All garbage-collecting languages have this problem, and as
> > far as I know all they can do is shrug and warn programmers not to
> > let go of the last C++ reference to an object if they know there
> > might be non-C++ references still lurking around.)
>
> You have to have libraries that support this mechanism. I am working on
> an interpretation of NIHCL which uses my refs instead of pointers.
>
> >
> > What if you have virtual base classes, and there are only references
> > to the base part of an object?  The derived part of the object has
> > a pointer to the base part but not the other way around, so the
> > derived part might be collected in this case.  Can this ever be a
> > problem?
> >
> This is a circular reference situation my solution cannot handle.
> >
> > Some food for thought,
> >                                 -- Dave
> > --
> > Dave Gillespie
> >   [e-mail], uunet!synaptx!daveg
> >   or: [e-mail]
>
>
> I would very much like to know what you think of my proposed solution.
>
> /jonas
>