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.