Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers - Another Proposal
Message-ID: <3783@lupine.NCD.COM>
Date: 8 Feb 91 05:33:04 GMT
References: <1991Feb5.021414.22979@cpsc.ucalgary.ca>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 52

In article <1991Feb5.021414.22979@cpsc.ucalgary.ca> gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter) writes:
+I agree with Tim Atkins' assessment of dumb pointer temporary problems
+in Ron Guilmette's most recent smart pointers proposal (the one that
+overloads operator& and operator T&).  These problems can be overcome
+in single-tasking, serially garbage collected applications if the
+compiler understands that for expressions involving smart pointers:
+
+* all side effects of evaluating a component of an expression must
+  take effect before evaluating the next component, and
+
+* the RHS of primitive assignment operators (including +=, ++, etc.)
+  must be evaluated before the LHS is evaluated.

If my proposal for allowing *complete* overloading of `T::operator T&'
and `T::operator&' were to be accepted, you *would not* need any additional
help from the compiler.  You would however be required to write your code
carefully (and well) within those few regions of your program where the
dumb pointers were indeed allowed to roam freely.

In particular, once you had generated a dumb pointer value which pointed
to some object, you would need to avoid deleting that object until you
were sure that the given dumb pointer value (and any replicas of it)
would never be used again.

+Additional compiler support is required to support
+parallel and incremental collectors and parallel applications.

I never said it wasn't.  That is a separate problem from the one my
proposal was trying to address.

+There are other problems with the proposal.  For instance:
+
+* it is not clear in function signatures whether or not a pointer is
+  smart, and

Huh?  That's entirely cryptic.

+* there is no way to explicitly use a dumb pointer to a smart class,
+  even if a developer knows that such use is safe.

That's totally incorrect.  Obviously, whenever a member function of a
"smart" class is called, it gets a `this' pointer which is a dumb
pointer to an object of the class.  The `this' pointer can be used
in any and all ways that a pointer to such an object may be used.

What's the problem?

-- 

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