Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!fernwood!lia!jgro
From: jgro@lia (Jeremy Grodberg)
Newsgroups: comp.lang.c++
Subject: Re: Smart pointers and stupid people (was: garbage collection...)
Message-ID: <1991Jan2.205606.1020@lia>
Date: 2 Jan 91 20:56:06 GMT
References: <1990Dec20.045909.7681@rice.edu> <CLINE.90Dec21171912@cheetah.ece.clarkson.edu> <3071@lupine.NCD.COM> <3090@lupine.NCD.COM>
Reply-To: jgro@lia.com (Jeremy Grodberg)
Lines: 71

In article <3090@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>[...]
>I went on to propose a syntax for specifying that (for a given class)
>no regular (stupid? :-) pointers to that class could be declared or used.
>
>I've since realized that there was a rather serious problem with my
>proposal. [...]
>
>Here is an alternative proposal which solves this problem:
>[...]

It is easy to make pointers hard enough to use that programmers won't
use them, which I think is good enough.  By overloading & (the address-of
operator) and new() for the class, one can force them to return smart-pointers,
as Ron started to do in his proposal.  The only way left for people to create 
regular pointers to the objects is by new-ing an array.  The fact that a 
class' operator new() is not called when an array of that class' objects 
are created, and thus a class has no way to prevent creation of an arrary, is a 
much discussed shortcoming which I would invite everyone to complain 
about to Messrs. Stroustrup and Koenig.  While Ron's proposal might make
it possible to prevent allocating an array because the compiler would
not let you create the resulting pointer, that solution is very confusing
to the programmer; I would much rather have a new() operator that I could
overload to allocate an array of objects.

If you do the overloading I suggested, then a programmer will have to 
make a conscious effort to get a regular pointer to the object, which
one can presume they are doing because that is what is truely needed.
If the programmer unknowingly and inappropriately tries to take create a 
regular pointer to the object, they would get a useful and informative
compiler error saying something like "Can't convert a (classPtr) to a
(* class)." Thus you will have accomplished the main objective, which
is to prevent programmers from erroneously getting regular pointers to
the objects of the given class.  

The truely general solution is neither the above nor Mr. Guilmette's, but
rather to allow programmers to define a class pointer as another class.
For example:

class T;

class T* {
public:
  operator*();
  operator->();
  //...
private:
  T*(); // make constructor private, so no one can create one
  void* ptr;  // the actual address of the T object.
}

The problem with this proposal is that it completely changes the concept
of what a pointer is and can be, and would likely cause major ripples 
throughout the compiler.  You now need a new syntax to describe a regular
pointer to T.  I really want "ptr" to be a regular pointer to T, but
I can't call it a T* now.  And what should &T return by default, a T* or
a regular pointer?  Perhaps you could get away with 

T t;
void* regularPointer = &(void)t;
t = (T) *regularPointer;

but now you've blown a great big hole in the type-checking system.


Compared to many of the proposed enhancements to C++, I think adding language
support to restrict one's ability to create pointers to objects is too
difficult in relation to its utility to be considered at this time.
-- 
Jeremy Grodberg      "I don't feel witty today.  Don't bug me."
jgro@lia.com