diamond problem and virtual inheritance

[George_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

[SandipG]

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.

[George_George]

Thanks, Sandip! So, you mean virtual inheritance makes one copy of both methods and data? regards, George

[SandipG]

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]

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

[SandipG]

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]

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

[SandipG]

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]

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

[SandipG]

Yes unless there is no overriding of methods from the common ancestor as i said earlier.

Regards, Sandip.

[George_George]

I agree, thanks Sandip! regards, George

[laksh2204]

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?