Re: Is there any more benifits by virtual inheritance than resolving the "diamond problem" ?
"James Kanze" <james.kanze@gmail.com>
OK. The article isn't written all that clearly, but if I
understand the first section correctly, the problem would only
occur in C++ if you used virtual inheritance; virtual
inheritance creates the diamond problem, rather than solves it.
No, virtual inheritance is a solution to the diamond problem.
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.
That is the strange view.
You design things in abstract, and (say in UML) discover that you have
ostream and istream that work fine in solo, and need iostream, that merry
them. But they already have that ios as base class, that *shall* be common
in iostream. (if actually drawn the usual way looks like a rombus...).
The design with the requirements is far from any kind of implementation, so
it can hardly be created from existance of virtual inheritance. IIRC
virtual inheritance's entering C++ was massively motivated by that iostream
library design, without which it could not be implemented to that spec.
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).
The class is clearly common -- the question is whether the object is common
or not.
Just often the "bace class sub-object" is in practice abbreviated as "base
class" then it can create this very confusion.
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.
If A is just interface there's obvoisly no state. In case of ios it very
likely has state.
In old days of C++ we had many Object - based hierarchies. With Object
having RTTI primitives, and possibly factory support. And most anything was
supposed to derive from Object or some of its descendant provided by the
framework. Brobably had some state too. Though MI was pretty hosed with
those beasts unless one discovered that deriving from object is better
dismissed ;-))
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.
Ah, do we have abdundance of reasonably good OO languages?
What they should pass isn't really the question. The question
is whether they should have separate sub-objects. Most of the
time, at least in the case of public inheritance, they
shouldn't; sometimes they should.
And for private inheritance they most likely shouldn't.
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.
Certainly provided that your supposedly OO-supporting language allows a
solutio that looks like the model. If not, you have quite a problem don't
you? ;-)
The reason I don't understand what it is is that so many people
present so many different opinions about what it is. And that
to date, no one has shown me anything which could be considered
a problem with the diamond inheritance hierarchy; the problem
could be (in some other languages) that they don't support the
diamond hierarchy---a no-diamond problem.
Hm, that looks like another vocabulary issue.