Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!alberta!cpsc.ucalgary.ca!news
From: gintera@fsd.cpsc.ucalgary.ca (Andrew Ginter)
Newsgroups: comp.lang.c++
Subject: Re: Smart Pointers - Another Proposal
Message-ID: <1991Feb8.212951.6212@cpsc.ucalgary.ca>
Date: 8 Feb 91 21:29:51 GMT
References: <1991Feb5.021414.22979@cpsc.ucalgary.ca> <3783@lupine.NCD.COM>
Sender: gintera@cpsc.ucalgary.ca (Andrew Ginter)
Organization: U. of Calgary Computer Science
Lines: 20
Nntp-Posting-Host: fsd

In article <3783@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
> 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.

I see now.  In your proposal, most designers of an "access controlled"
class X would not implement a public "operator ->" for the smart
pointer class referring to objects of type X.  Such an operator would
represent an undesirable "leak" of dumb pointers and references to X
into areas of an application which X's designer can't anticipate.

This means that most "generally useful" operations on X would be
phrased as static member functions or as "friend" functions.  This is
because most users of the class will not be able to use a smart
pointer x to X to say "x -> foo ()".  They'll have to say something
like "X::foo (x)" or just "foo (x)".

Andrew Ginter, 403-220-6320, gintera@cpsc.ucalgary.ca