class A { public: void eat(){ cout<<"A";} }
class B: virtual public A { public: void eat(){ cout<<"B";} };
class C: virtual public A { public: void eat(){ cout<<"C";} };
class D: public B,C { public: void eat(){ cout<<"D";} };
int main(){
A *a = new D();
a->eat();
}
I…
Bloated Code. Why should you have to write code for Class C and Class B? When All you want todo is use Class D
You have to worry about the whole Heirarchy (eg, the whole jungle).
Debuging becomes harder. On instantiation of D was B called or was it C?
The above example is the simplest to illustrate the point. Imagine production scenarios with deep heirarchy.
Why do you do it this way, if there is a simpler and better approach? You can use a hammer to drill a hole, but maybe that is the wrong tool for the task.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How does virtual inheritance solve the "diamond" (multiple inheritance) ambiguity?
I…
Bloated Code. Why should you have to write code for Class C and Class B? When All you want todo is use Class D
You have to worry about the whole Heirarchy (eg, the whole jungle).
Debuging becomes harder. On instantiation of D was B called or was it C?
The above example is the simplest to illustrate the point. Imagine production scenarios with deep heirarchy.
Why do you do it this way, if there is a simpler and better approach? You can use a hammer to drill a hole, but maybe that is the wrong tool for the task.