diamond problem and virtual inheritance
-
Hello everyone, Just want to confirm a basic concept when reading a couple of documents about diamond problem and virtual inheritance. 1. Diamond problem covers both ambiguity methods and data member variable? 2. Virtual inheritance only solves ambiguity data member issue (making data member one copy)? 3. So, it is not correct to say virtual inheritance solves diamond problem 100% since ambiguity member methods is not covered and solved? thanks in advance, George
-
Hello everyone, Just want to confirm a basic concept when reading a couple of documents about diamond problem and virtual inheritance. 1. Diamond problem covers both ambiguity methods and data member variable? 2. Virtual inheritance only solves ambiguity data member issue (making data member one copy)? 3. So, it is not correct to say virtual inheritance solves diamond problem 100% since ambiguity member methods is not covered and solved? thanks in advance, George
Hi, Try the following code it might help you: ========================================================================== #include "iostream.h" #include "stdio.h" class A { public: int m_nAInt; A(int n = 1):m_nAInt(n) { cout << "Class A Constructor called" << endl; } Display() { cout << "A::Display()" << endl; } }; class B: public virtual A { public: B() { cout << "Class B Constructor called" << endl; } }; class C: public virtual A { public: C() { cout << "Class C Constructor called" << endl; } }; class D: public B, C { public: D() { cout << "Class D Constructor called" << endl; } }; int main(int argc, char* argv[]) { D dObj; dObj.Display(); return 0; } ==========================================================================
-
Hi, Try the following code it might help you: ========================================================================== #include "iostream.h" #include "stdio.h" class A { public: int m_nAInt; A(int n = 1):m_nAInt(n) { cout << "Class A Constructor called" << endl; } Display() { cout << "A::Display()" << endl; } }; class B: public virtual A { public: B() { cout << "Class B Constructor called" << endl; } }; class C: public virtual A { public: C() { cout << "Class C Constructor called" << endl; } }; class D: public B, C { public: D() { cout << "Class D Constructor called" << endl; } }; int main(int argc, char* argv[]) { D dObj; dObj.Display(); return 0; } ==========================================================================
What is the issue, tony_udz? Could you clarify please? You code runs ok without any compile/build warning/errors. Here is the output.
Class A Constructor called
Class B Constructor called
Class C Constructor called
Class D Constructor called
A::Display()regards, George
-
What is the issue, tony_udz? Could you clarify please? You code runs ok without any compile/build warning/errors. Here is the output.
Class A Constructor called
Class B Constructor called
Class C Constructor called
Class D Constructor called
A::Display()regards, George
-
Hi George,
George_George wrote:
You code runs ok without any compile/build warning/errors.
That means virtual resolved methods as well as data member ambiguity so that does not clear your doubt. I hope it helps..
Regards, Sandip.
Thanks, Sandip! So, you mean virtual inheritance makes one copy of both methods and data? regards, George
-
Thanks, Sandip! So, you mean virtual inheritance makes one copy of both methods and data? regards, George
George_George wrote:
So, you mean virtual inheritance makes one copy of both methods and data?
Yes unless you do not override the common method in both derived classes. In above case if you override Display method in both derived classes you will get ambiguity error.
Regards, Sandip.
-
George_George wrote:
So, you mean virtual inheritance makes one copy of both methods and data?
Yes unless you do not override the common method in both derived classes. In above case if you override Display method in both derived classes you will get ambiguity error.
Regards, Sandip.
Thanks Sandip, I have tried that when overriding in both classes, there will be compile error regarding the ambiguity issue. But when overriding only in one class, there is no compile error regarding the ambiguity issue, why?? regards, George
-
Thanks Sandip, I have tried that when overriding in both classes, there will be compile error regarding the ambiguity issue. But when overriding only in one class, there is no compile error regarding the ambiguity issue, why?? regards, George
George_George wrote:
But when overriding only in one class, there is no compile error regarding the ambiguity issue, why??
In that case i think preference is given to overridden method. and you can always use scope resolution operator to execute desired method :)
Regards, Sandip.
-
George_George wrote:
But when overriding only in one class, there is no compile error regarding the ambiguity issue, why??
In that case i think preference is given to overridden method. and you can always use scope resolution operator to execute desired method :)
Regards, Sandip.
Thanks Sandip, "In that case i think preference is given to overridden method." -- you mean when calling D.Display, there are two choices, 1. D::B::Display; 2. D::C::A::Display. But since (1) is "more" overridden than (2), (1) is preferred, but if we derive Display in both B and C, D will have no choice and there will be ambiguity compile error? regards, George
-
Thanks Sandip, "In that case i think preference is given to overridden method." -- you mean when calling D.Display, there are two choices, 1. D::B::Display; 2. D::C::A::Display. But since (1) is "more" overridden than (2), (1) is preferred, but if we derive Display in both B and C, D will have no choice and there will be ambiguity compile error? regards, George
George_George wrote:
"In that case i think preference is given to overridden method." -- you mean when calling D.Display, there are two choices, 1. D::B::Display; 2. D::C::A::Display. But since (1) is "more" overridden than (2), (1) is preferred,
Yes from the behavior it seems like that. Even i did not come across any documents that states above behavior.
Regards, Sandip.
-
George_George wrote:
"In that case i think preference is given to overridden method." -- you mean when calling D.Display, there are two choices, 1. D::B::Display; 2. D::C::A::Display. But since (1) is "more" overridden than (2), (1) is preferred,
Yes from the behavior it seems like that. Even i did not come across any documents that states above behavior.
Regards, Sandip.
Thanks Sandip, Here is what I learned from you -- virtual inheritance solves both member method and member data issue -- so we can say virtual inheritance solves all diamond problem issues (both ambiguity member method and data member). Could you review and confirm my understanding now is correct please? :-) regards, George
-
Thanks Sandip, Here is what I learned from you -- virtual inheritance solves both member method and member data issue -- so we can say virtual inheritance solves all diamond problem issues (both ambiguity member method and data member). Could you review and confirm my understanding now is correct please? :-) regards, George
-
Yes unless there is no overriding of methods from the common ancestor as i said earlier.
Regards, Sandip.
I agree, thanks Sandip! regards, George
-
Hi George,
George_George wrote:
You code runs ok without any compile/build warning/errors.
That means virtual resolved methods as well as data member ambiguity so that does not clear your doubt. I hope it helps..
Regards, Sandip.
I have some queries here.. 1. By making the inheritance virtual how the ambiguity is actually resolved? I mean, what this virtual inheritance does internally? Does it create another vptr of another vtable? if it is so how does the new vtable looks like?? 2. And as the diamond problem says that there is an ambiguity that whether D will have path A->B->D or A->C->D A / \ B C \ / D So after removing ambiguity which path is taken?