[comp.lang.c++] mi and virtual functions/ambiguity

stanl@cbnewsm.ATT.COM (stanley.b.lippman) (09/28/89)

>>I have been reading Lippman's "C++ Primer" to familiarize myself with
>>the features of C++ 2.0.  On page 312, in discussing function name
>>ambiguities that can arise from multiple inheritance, he gives an example
>>and states:

>>    "When the inherited members that share the same name are all
>>     member functions, it is therefore a good design strategy to
>>     define a derived class member function of the same name."

>>I wanted to try this out myself and see how it worked with virtual
>>functions.  I do not yet have AT&T C++ 2.0 available to me, but I do

>> EXAMPLE deleted
>>% g++ -o test1 test1.C
>>% test1
>>garpA:
>>A::foo() : a = 1
>>B::foo() : b = 1
>>C::foo() : c = 1
>>garpB:
>>B::foo() : b = 2
>>garpC:
>>A::foo() : a = 2
>>B::foo() : b = 3
>>C::foo() : c = 2

The 2.0 output, regardless of the ordering of the base
class declarations, is the following:

garpA:
A::foo() : a = 1
B::foo() : b = 1
C::foo() : c = 1
garpB:
A::foo() : a = 2
B::foo() : b = 2
C::foo() : c = 2
garpC:
A::foo() : a = 3
B::foo() : b = 3
C::foo() : c = 3

here is an example of the effect of inheriting two virtual
functions of the same name without providing an instance in 
the derived class:

class x { public: virtual void foo(); };
class y { public: virtual void foo(); };
class z : public x, public y { public: virtual void f(); };

extern "C" void printf(const char*, ... );
void x::foo(){printf("x::foo\n");}
void y::foo(){printf("y::foo\n");}
void z::f();}

main() {
z zz;
x *px = &zz;
y *py = &zz;
px->foo(); // outputs x::foo
py->foo(); // outputs y::foo

z *pz = &zz;
// pz->foo(); // compile-time error: ambiguous
}


>>I can see by the output how the compiler implementation behaves
>>when the order of base classes is changed for the derived class C.
>>To me it is rather non-intuitive that the results should differ
>>based simply on this ordering.  Is this a feature of 2.0?  Does the
>>(hypothetical) language standard say that behaviour in this case is
>>undefined?  Lippman's book gives no indication that I can see.
>>Does the AT&T 2.0 compiler work the same way as GNU C++?

Again, the behavior does not change depending on the order of
base class declarations.  

stan lippman
at&t bell laboratories
stan@mozart.att.com

>>Kurt W. Luoto
>>I'm unsure of my mailer. Try  kurtl@fai.fai.com  or  ...!sun!fai!kurtl