Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!seismo!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Smart pointers and Stupid people (my reactions and a new idea)
Message-ID: <70385@microsoft.UUCP>
Date: 1 Feb 91 18:28:35 GMT
References: <3348@lupine.NCD.COM> <1991Jan19.190403.24325@clear.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 36

In article <3348@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
|Now for my detailed comments on the "smart pointer problem" discussion
|so far.  (This is where it really starts to get biased! :-)
|--------------------------------------------------------------------------
|
|The solution proposed by Bob Martin and (independently) also by Jeremy
|Grodberg to allow the type T* to be  treated like a class (which can
|be declared and which can have member functions and operators defined
|for it) is clever and I had myself considered it, however I fear that
|Bjarne will never like it.  The reason?  Well, it makes the language
|"mutable" (in Stroustrup's terms).  One early (and related) idea
|which I had some time ago for solving this "smart pointer" problem
|was to allow stuff like:
|
|	T*& operator= (T*, T*&);
|	T operator* (T*);
|
|In effect, I wanted to let the user just redefine the meaning of = and
|(unary) * for plain old pointer types.  If you could do that, then you
|could be in complete control of all operations done with stupid pointers.

Hm, again, I can see where if T is a built-in type, say an int, or a 
type derived from a built-in type, say and int[100], or an int*,
then it makes sense not to allowed the basic built-in types to 
be mutated.  This would give one programmer the right to change the 
meaning of another programmer's programming efforts.

However if T is a class type, say a FOO, or a type derived from a class
type, say a FOO* or a FOO[100], then the only people affected by mutating
the meaning of T are people who have bought into using that particular
type.  This seems more than fair to me.  Thus, as I suggested on
comp.std.c++, I don't see why overloading is allowed only on 
class types.  It would seem that FOO*'s,  FOO[100]'s, and enums would
also be "fair" types to overload.  The only people affected would be
those people who *choose* to use those class types, enum types, or types
derived from those class or enum types.