Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <71437@microsoft.UUCP>
Date: 21 Mar 91 19:41:18 GMT
References: <11152@jarthur.Claremont.EDU> <624@taumet.com> <1991Mar17.184122.717@mathcs.sjsu.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 119

In article <1991Mar17.184122.717@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
|The most important question is of course: Does it solve any problems? Recently
|it was generally agreed that it would be useful for defining an access class
|which can be both an lvalue and an rvalue. Is anyone aware of another use for
|it?

Overloaded operator dot is for all practical purposes necessary in order
to be able to make "smart reference classes" just as today one can make
"smart pointer classes."  The question then becomes why would one prefer
to use "smart reference classes" over "smart pointer classes"  ???

[I use the term "smart" here in a very loose sense.  By a "smart pointer
 class" I really mean any class that is implemented to act as if it is 
 a pointer -- whether that class does anything intelligent, or simply
 forwards all requests to the pointed-at object is immaterial to my 
 discussion.  The same holds true for "smart reference classes"]

Two situation where "smart reference classes" are clearly preferrable
to "smart pointer classes" are: 1) when such an object has to act like
a value, and 2) when such an object has to act like a normal object.

[A simpler way to say this would be to state that smart reference classes
 are always preferred to smart pointer classes -- except when you're trying
 to make a pointer class -- but that sounds like a circular argument.]

Lets see how this might be used.  First case is when a smart reference
class has to act like a value.  Matrices have been a hot topic recently --
let's consider how one would make a reference counted matrices class.
Lets call the class that implements the actual storage requirements and
reference count of the matrices the ActualMatrix class, and have the
smart reference class simply called Matrix -- in order to hide implementation
details from the end users.  We want to be able to write code like this:

Matrix ReadANewMatrix(int row, int col)
{
	Matrix A(row, col);

	for (int i=0; i<row; ++i)
		for (int j=0; j<col; ++j)
			A[i][j] = ReadAValue();
	return A;
}

Remember that Matrix is actually a smart reference class -- when a Matrix
is constructed, an ActualMatrix is being created in the background off
of heap.  The Matrix copy-constructor and assignment simply adjust the
reference count in ActualMatrix.  [I'll leave the details of when, if ever,
separate copies of ActualMatrixes are generated to the discretion of the
reader.]

If its not obvious to you why you wouldn't want to use a smart pointer
implementation instead, consider how such an implementation ought to 
look in order to mimic pointers:

MatrixPtr ReadANewMatrix(int row, int col)
{
	MatrixPtr A = new ActualMatrix(10, 20)

	for (int i=0; i<row; ++i)
		for (int j=0; j<col; ++j)
			(*A)[i][j] = ReadAValue();
	return A;
}

Which doesn't do nearly as good a job of hiding the abstraction.  A similar
case would be reference counted string classes.

The second case where "smart reference classes" are preferred to smart
pointer classes is when you want the implementation details to be hidden.
If you make a class Foo which delegates a portion or all of its actual
work to Bar, do you really want to make it clear that this delegation
is being performed, or is the delegation an implementation
detail for Foo that should remain hidden?  If the implementor of Foo want
to hide the delegation [and more than a couple methods are being delegated]
then you really need operator dot, so that you can just say: "delegate 'all'
these methods to Bar."  Consider the case of a named object that's huge,
knows its huge, and thus tries to keep its representation on disc most of
the time:

Class  TryToBeDiscResident : public ThingsProtocol
{
	FileName fileName;	// where to find the object when *its not*
				// in memory!

	Thing* p;		// where to find the object when *it is* in 
				// memory!
public:
	Thing& operator.();
	....
};

Thing& TryToBeDiscResident::operator.()
{
	if (p == NULL)
	{
		p = GoGetThingFrom(fileName);
	}

	return *p;

}

[I'll leave it to the reader to decide when and how Things that 
TryToBeDiscResident take themselves back out of memory and onto disc.]

Note that its possible to create "smart reference classes" today -- even
without overloadable operator dot -- and lots of people are creating
such smart reference classes -- its just that to do so requires the
author to manually write a "trivial" [but annoying] forwarding method
for each and every method in the protocol to be forwarded, and afterwards
to manually provide software maintanence to keep all those forwarding
methods up-to-date.  Whereas is overloadable operator dot is supported,
not only is it not necessary to manually write all the forwarding 
methods -- in many situations one could use a standard "smart reference
class" template to do "all" the work for you.

In summary: I believe overloadable operator dot is *at least* as useful as
overloadable operator->, and is necessary if you want to be able to use
templates to make smart reference classes.