Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!usc!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers -- A proposed language extension
Keywords: smart pointers, garbage collection
Message-ID: <3451@lupine.NCD.COM>
Date: 23 Jan 91 09:03:20 GMT
References: <1991Jan6.072110.27136@cpsc.ucalgary.ca> <1991Jan16.224703.7647@xanadu.com> <1991Jan18.014050.27108@cpsc.ucalgary.ca>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 84

In article <1991Jan18.014050.27108@cpsc.ucalgary.ca> gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter) writes:
+
+Guilemette's claim that support for overloading the "address of
+member" operator prevents dumb pointers into the middle of smart
+objects is wrong.  When invoking a member function of a data member of
+a smart object (smart object = one that has a smart pointer defined
+for it), there is nothing that requires the data member itself to be a
+smart object.

Now I understand the point that you were trying to make.  I believed before
that the only thing that you were worried about was the (non-existant)
problem of getting a dumb pointer via `&object.member'.  As I say, that
is not a problem because noadays, C++ is defined to give you a very
special kind of pointer (a pointer-to-member) when you use such a
construct.

You are correct however that if I do `object.data_member.func_member()'
then the invoked `func_member' will get (as its `this' pointer) a pointer
to just the `data_member' subpart of `object'.  You are also correct that
this is worth thinking about, because if (while func_member is being
executed) the entire `object' moves (or is deleted) you are in big
trouble.

While this question is worth thinking about, it is not a critical
concern for the problem I was hoping to see a solution for.  Basically,
I just didn't want dumb pointers to objects (or, as you correctly note,
even dumb pointers to subparts of objects) to be "leaking out" all over
the program.  In the case of `object.data_member.func_member()' you could
prevent dumb pointers to data members from "leaking" all over the map
simply by doing what C++ programmers often do anyway... i.e. by making
`data_member' private to the class T (where T is the type of `object').
If you did that, then you have done a part of what I was asking for...
you have "encapsulated" pointers to `object' (or its subparts) to the
point where they might only be floating around in *some* (but not all)
parts of the program.

Of course you need additional language support to complete the "encapsulation
of the dumbness", but even if you have the additional language support,
the programmer *must* cooperate if you are to have any hope at all of
keeping the dumbness confined (to a limited area of code).

+Guilemette's smart pointer proposal seems to assume that it's possible
+to exclude dumb pointers to smart objects from some lexical contexts.
+While this is true, I think the number of such contexts is more
+limited than most people would consider useful.  In particular,
+consider the statement:
+
+  X -> A = boo ();
+
+where X is a smart pointer and boo is a function that sometimes
+triggers a compacting garbage collection.  The order of evaluation of
+this expression is undefined, and the left hand side (lhs) of the
+expression is an lvalue - a dumb pointer to A.

HOLD IT!  STOP RIGHT THERE!  Who says that an lvalue is the same thing as
a pointer?  This is an interpretation of C/C++ semantics I have never heard
before!!!

+If the language evaluates the lhs of the expression before evaluating
+the rhs and boo triggers a collection, the dumb pointer will be stored
+in a temporary or in a register during the collection.

You have noted a case where the ordering criteria for C/C++ operations
is sufficiently weak that a programmer could (as in your example) get
himself into trouble.  Does that mean that attempts to improve upon
the safety of smart pointers should be abandoned?  I think not.

+Gregory's claim that normal pointers to objects are OK as long as
+a smart pointer still refers to the object is of course true for
+non-compacting collectors.  However, this is a rule USERS must
+enforce - compilers can't...

Right.  Compilers can only give you the basic tools to write "good" or
"safe" code.  They cannot actually write the code for you.  You have
to help a little. :-)

As I said earlier, you (the programmer) must do your part to "encapsulate
the dumbness".

-- 

// 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.