Re: Is there any more benifits by virtual inheritance than resolving
the "diamond problem" ?
James Kanze wrote:
The diamond problem happens with multiple inheritance when the
multiple base classes have a common base class of their own.
Which only happens if there is virtual inheritance.
You are confusing classes with objects.
If B inherits from A, and C inherits from A, then A is a common base
class to both B and C. (For example, if a function expects a reference
of type A, an object of type B or type C can be given to it.)
Diamond inheritance introduces an ambiguity: If D inherits from both B
and C, should A be instantiated only once in objects of type D, or
should it be instantiated twice, once for the B part and once for the D
part inside D? *That* is the diamond problem.
Virtual inheritance is *one solution* to that problem (not the only
possible solution, but one of them).
The problem is: Should this common base class be duplicated in
the multiple-inherited class, or should it be merged into one?
I think we have a problem of vocabulary. If the common base
class isn't merged, it isn't common---it's two distinct bases
(which perhaps happen to have the same type).
You are indeed confusing the concepts of class and object
(instantiation of that class). A is still a base class for both B and C
regardless of whether it's instantiated once of twice inside D.
The question is whether A should appear only once inside D (and thus
shared by both B and C) or not.
If, for example, class A has a member function named foo(),
class B inherits from A, class C inherits from A, and finally
class D inherits from both B and C, and then you create an
object of type D and call its foo() member function, what
should happen?
Exactly. Now forget about A. Remove it completely from the
example: class D inherits from both B and C, both B and C
defined foo(), and you call foo in an instance of D. Nothing
diamond-like in sight, and exactly the same problem.
(Obviously, the author of the Wikipedia article doesn't really
understand what he is talking about. Happens sometimes.) And
even with A, if the problem occurs, inheriting virtually doesn't
change anything.
Knowing your vast knowledge about C++, I'm seriously surprised that
you don't know this better. If A has a foo() function and you use
virtual inheritance in a diamond inheritance situation, there's no
ambiguity anymore:
//-------------------------------------------------------------
#include <iostream>
class A
{
public:
void foo() { std::cout << "A::foo()\n"; }
};
class B: virtual public A {};
class C: virtual public A {};
class D: public B, public C {};
int main()
{
D d;
d.foo(); // Compiles ok, no ambiguity
}
//-------------------------------------------------------------
Now remove those 'virtual' keywords and you'll get a compiler error
because the "d.foo()" call is ambiguous.
The reason why there's no ambiguity with virtual inheritance is that
with it, A is instantiated only once inside the 'd' object and thus
there's only one A::foo() to be called (or technically speaking, there's
only one "this" pointer to be used when calling A::foo(), so there's no
ambiguity).
Moreover, if a function in B calls a function in A which
modifies some member variable of A, and some other function in
C calls that same function in A, what should happen?
A shouldn't have any member variables:-). (Seriously, it is
*usually* a design error if A has any state. But of course,
like most rules, there are occasional exceptions.)
Base classes should not have any member variables? What are you
talking about? Where are you getting this from?
More importantly, what should happen depends on the design, but
most often, what should happen is that there is only one
instance of A. In other words, you should have a diamond. (In
which case, the diamond isn't the problem, it's the solution.)
You are not understanding what "diamond inheritance" means. It's a
diamond formed in the inheritance hierarchy.
The diamond inheritance shape is not the problem. How to instantiate
objects of the most derived type is the problem.
Should both the B and C calls cause the *same* member variable
to be modified, or should these two members be separate (so
that B has its own state, separate from C which has its own)?
It depends on the design. Any reasonably good OO language will
support both.
You are missing the point. I was describing why the "diamond problem"
is a problem. It was not a question I asked you.
And none of this, IMHO, deserves any name with the word
"problem" in it.
It does because there is an ambiguity, which is the problem. And
there's no universal solution to the problem. Instead, you have to make
a design decision about which solution you want to use, and every
solution has its own advantages and disadvantages. (Many OO languages
avert the problem completely by not supporting multiple inheritance at all.)
Not using virtual inheritance is taking one stance (B and C
should be separate and have no common base), while using
virtual inheritance is taking another (their bases should be
merged). Thus virtual inheritance offers one solution to the
problem.
First, there's no problem; your design determines whether you
need a diamond or not. And the choice between virtual and
non-virtual inheritance allows choosing the appropriate solution
for the design.
What you wrote is contradictory. If there is no problem then no
solution should be needed either. However, as you yourself admit, the
programmer has to choose a solution. A solution is needed because there
is a problem (more specifically, it's a problem of ambiguity).
The duplication (or not) and the function call ambiguity are two
separate, orthogonal issues.
No, they aren't, because the base class member functions operate on
the base class member variables, and thus it makes a big difference
whether the base class has been instantiated once or twice in the most
derived class.
The reason I don't understand what it is is that so many people
present so many different opinions about what it is.
It seems to be that you are simply refusing to acknowledge that the
ambiguity presented by diamond inheritance is a problem needing a
solution. Rather contradictorily, you acknowledge the existence of the
solutions themselves, but not the problem they were created to solve.