«

Hi,

I wonder why is there an ambiguity in diamond
inheritance when we try to call the method in the
parent class from the class derived from multiple
(two)childs of the parent class.
Why C++ does not handle it internally and give us the
path to access the method in the parent class ?
Any constraints ?

Thx in advans,
Karthik Balaguru

On 6 Mar, 11:38, karthikbalaguru <karthikbalagur...@gmail.com> wrote:
>
> I wonder why is there an ambiguity in diamond
> inheritance when we try to call the method in the
> parent class from the class derived from multiple
> (two)childs of the parent class.
> Why C++ does not handle it internally and give us the
> path to access the method in the parent class ?
> Any constraints ?

See
http://www.parashift.com/c++-faq-lit....html#faq-25.9

karthikbalaguru wrote:

> Hi,
>
> I wonder why is there an ambiguity in diamond
> inheritance when we try to call the method in the
> parent class from the class derived from multiple
> (two)childs of the parent class.
> Why C++ does not handle it internally and give us the
> path to access the method in the parent class ?
> Any constraints ?

1. there are no C++ methods, there are only member functions of various
types, let's supose you mean normal (non static, non virtual) member
function

2. if it were to be able to call it, on what instance of the common base it
should do it? Because if you have a diamond, you got 2 instances of the
common base, one though one branch of the diamond and the other through the
other so it should call the member function on which of these instances?
Thus the ambiguity

If instead, you wanted to have a single common base even if it's inherited
(indirectly) multiple times then you should look over "virtual inheritance"
in your C++ book.

--
Dizzy

On Mar 6, 3:38*am, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> Hi,
>
> I wonder why is there an ambiguity in diamond
> inheritance when we try to call the method in the
> parent class from the class derived from multiple
> (two)childs of the parent class.
> Why C++ does not handle it internally and give us the
> path to access the method in the parent class ?
> Any constraints ?
>
> Thx in advans,
> Karthik Balaguru

Let's say we have four classes: A, B, C, and D
B & C both derive from A
D derives from B & C

D essentially "contains" two A sub-objects. One for the B part and
one for the C part. Consider the following code:

#include <iostream>

class A
{
int n;
public:
A(int i) : n(i) {};
virtual void f() { std::cout << "From A: " << n << std::endl; }
};

class B : public A
{
public:
B() : A(30) {};
};

class C : public A
{
public:
C() : A(50) {};
};

class D : public B, public C {};

int main()
{
D d;
d.C::f(); //prints 50
d.B::f(); //prints 30
return 0;
}

If both B & C had derived virtually from A:
class B : public virtual A {/*...*/};
class C : public virtual A {/*...*/};
Then D would only have one A sub-object. In this case, D would be
responsible for constructing A.

On Mar 6, 6:19*pm, dizzy <di...@roedu.net> wrote:
> karthikbalaguru wrote:
> > Hi,
>
> > I wonder why is there an ambiguity in diamond
> > inheritance when we try to call the method in the
> > parent class from the class derived from multiple
> > (two)childs of the parent class.
> > Why C++ does not handle it internally and give us the
> > path to access the method in the parent class ?
> > Any constraints ?
>
> 1. there are no C++ methods, there are only member functions of various
> types, let's supose you mean normal (non static, non virtual) member
> function
>
> 2. if it were to be able to call it, on what instance of the common base it
> should do it? Because if you have a diamond, you got 2 instances of the
> common base, one though one branch of the diamond and the other through the
> other so it should call the member function on which of these instances?
> Thus the ambiguity

I understand the Diamond Problem and the solution of "Virtual
Inheritance"
that is used to overcome ambiguity.
But, i wonder why should the Diamond problem arise. This should
be taken care by C++ internally and resolved. Why C++ could not
handle it internally without asking us to do the 'virtual
inheritance'?

Thx in advans,
Karthik Balaguru

> I understand the Diamond Problem and the solution of "Virtual
> Inheritance"
> that is used to overcome ambiguity.
> But, i wonder why should the Diamond problem arise. This should
> be taken care by C++ internally and resolved. Why C++ could not
> handle it internally without asking us to do the 'virtual
> inheritance'?


If c++ would automatically resolve the ambiguity, then how would you
be able to have 2 separate instances ?

Base Base
| |
| |
| |
Der1 Der2
\ /
\ /
\ /
Join


I know it would be a bad design to have such a structure, but just in
case someone wanted to have a non-diamond structure.... c++ allows
it.

On 2008-03-06 23:34:45 -0500, karthikbalaguru
<> said:

>
> I understand the Diamond Problem and the solution of "Virtual
> Inheritance"
> that is used to overcome ambiguity.
> But, i wonder why should the Diamond problem arise. This should
> be taken care by C++ internally and resolved. Why C++ could not
> handle it internally without asking us to do the 'virtual
> inheritance'?
>

"The Diamond Problem" arises because the writer of a class hierarchy
didn't understand how inheritance works.

struct A
{
int i;
};

struct B : A
{
};

struct C : A
{
};

struct D : B, C
{
void f();
};

void D::f()
{
i = 3; // error: ambiguous
}

There are two separate "i" members in D. There's no way the compiler
can "handle it internally". You have to say what you mean:

void D::f()
{
B::i = 3; // OK: B's "i" member
}

If you don't want to have two "I" members in D, then the inheritance
hierarchy as written above is wrong. If the design calls for only one A
subobject, you do that by making A a virtual base everywhere. Then
there's only one "i" member in D. But note that that's a design
decision, not an implementation decision. Either you have only one A
subobject, in which case "i" is unambibuous, or you have two, and you
have to say which one you mean.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

On 2008-03-07 08:07:37 -0500, Shobhit Gupta <> said:

>
> If c++ would automatically resolve the ambiguity, then how would you
> be able to have 2 separate instances ?
>
> Base Base
> | |
> | |
> | |
> Der1 Der2
> \ /
> \ /
> \ /
> Join
>
>
> I know it would be a bad design to have such a structure, but just in
> case someone wanted to have a non-diamond structure.... c++ allows
> it.

It's not a bad design if it's the correct solution to the problem. For
example, if Base is a node that can for a linked list, Join can be an
element in two lists.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

> It's not a bad design if it's the correct solution to the problem. For
> example, if Base is a node that can for a linked list, Join can be an
> element in two lists.


That sounds right. I was thinking of other scenarios, like having BASE
class contain some information. (In that case its better to use
composition.)
But thats something very true, if anything is a correct solution, its
probably the right design for the user.

On Mar 6, 8:34*pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:

> I understand the Diamond Problem and the solution of "Virtual
> Inheritance"
> that is used to overcome ambiguity.
> But, i wonder why should the Diamond problem arise. This should
> be taken care by C++ internally and resolved. Why C++ could not
> handle it internally without asking us to do the 'virtual
> inheritance'?
>
> Thx in advans,
> Karthik Balaguru

Read my example above and consider this:
d.C::f() prints out 50
d.B::f() prints out 30
What should d.f() print out?

Should the compiler just guess which one you meant? Or are you asking
why non-virtual inheritance is the default?