daniel@terra.ucsc.edu (Daniel Edelson) (01/31/91)
Even if we had a ``perfect'' implementation of smart pointers,
I don't think that would be enough to permit robust copying
garbage collection. Unfortunately.
By perfect I mean that all of the application's pointers of
type (node *) were smart pointers rather than raw pointers.
Perhaps I'm using the word perfect in a misleading way. If so,
I hope someone will clairify.
Case in point:
struct node { int i; };
int * foo()
{
smart_pointer_to_node p = new node;
int * i = &p->i;
return i;
}
How do we keep the node from being collected now that
the smart pointer to it has been destroyed?
What's the best course of action here? Forbid taking the
address of members of a collected object? I already place
so many restrictions on code that uses my garbage collector
that this seems unattractive.
I am not a proponent of conservative garbage collection, but the
more I examine these problems the more I lean that way.
Daniel Edelson
daniel@cis.ucsc.edurfg@NCD.COM (Ron Guilmette) (02/08/91)
In article <11707@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel Edelson) writes:
+
+Case in point:
+
+ struct node { int i; };
+
+ int * foo()
+ {
+ smart_pointer_to_node p = new node;
+ int * i = &p->i;
+ return i;
+ }
+
+How do we keep the node from being collected now that
+the smart pointer to it has been destroyed?
+What's the best course of action here? Forbid taking the
+address of members of a collected object?
Well... essentially... yes.
Actually, "forbid" is not the correct term. Rather than a total prohibition,
you could simply *encapsulate* the ability to take the address of the
member called `i' within the `struct node' type.
That's quite easy to do. Just make your data members (e.g. `i') private
to their containing classes.
You ought to be doing that anyway.
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg
// Motto: If it sticks, force it. If it breaks, it needed replacing anyway.