Path: utzoo!attcan!uunet!microsoft!alonzo
From: alonzo@microsoft.UUCP (Alonzo Gariepy)
Newsgroups: comp.lang.c++
Subject: Re: Implementing virtual functions that return reference to self
Message-ID: <7423@microsoft.UUCP>
Date: 18 Aug 89 00:47:05 GMT
References: <8975@thorin.cs.unc.edu> <2045@cadillac.CAD.MCC.COM> <480@osc.COM>
Reply-To: alonzo@microsoft.UUCP (Alonzo Gariepy)
Organization: Microsoft Corp., Redmond WA
Lines: 42

In article <480@osc.COM> strick@osc.UUCP (henry strickland) writes:
...
>This is one of the fundamental differences between single- and
>multiple- inheritance in C++.  This is what I was missing, and 
>is probably what many of us who have been using single-inheritance
>C++ for a couple of years are not used to thinking:
>
> +---------------------------------------------------------------------------+
> |  In a multiply-inherited object, the pointers to derived classes are NOT  |
> |  necessarily the same addresses as the pointers to their base classes.    |
> +---------------------------------------------------------------------------+

This is a simple implementation detail.  The problem you have cited for 
multiple inheritance applies as much to polymorphic use as it does to
variable return types.  Any pointer adjustments are identical to those
which must take place when you write things like:

	SomeBaseClass 		*pSBC;
	MultiplyDerivedClass 	MDC;

	pSBC = (SomeBaseClass *)&MDC;     // pointer adjustment needed

I think the biggest point being missed in this discussion about alternate
return types is that all the work is done on the calling side at compile
time so that full information about involved classes is readily available.

With a preprocessor that knows about C++ calling syntax and a compiler that
allows compound expressions to yield L-values (G++), you can get the correct
effect with the macro definition:

	#define x.func(y,z) (x.thefunc(y, z), x)

this works equally well for virtual or inherited functions.

But this is not a satisfactory solution because:  if x is an expression it 
is evaluated more than once; more logic is needed to handle the ->func() case;
no such preprocessor exists; compound expressions yielding L-values are
nonstandard; you need to invent a new name for the macro; and the idea is so
simple that it can be implemented without preprocessing right in the compiler.

Alonzo Gariepy				// these opinions do not reflect
alonzo@microsoft			// the policies of Microsoft Corp.