Dealing with a Diamond of Death

[Rocketmagnet]

Hi all,

I have been kind of forced (honestly) into writing a class structure
which contains a Diamond of Death, and I'm not entirely sure what to
do about it. This is a simplified version of my class structure:


class entity
{
public:
entity() {}

int a;
};


class item : public entity
{
public:
item() {}

int b;
};


class loop : public virtual item
{
public:
loop() {}

int c;
};


class path : public virtual item
{
public:
path() {}

int d;
};

class test : public path, public loop
{
public:
test() {}

int e;
};



int _tmain(int argc, _TCHAR* argv[])
{
ENTITY *entity_test = new test();
ENTITY *entity_loop = new loop();

loop* l = (loop*)entity_loop; // cannot convert a 'ENTITY*' to a
'loop*'
// conversion from a virtual base
class is implied

test* t = (test*)entity_test; // cannot convert a 'ENTITY*' to a
'test*'
// conversion from a virtual base
class is implied

return 0;
}


Can anyone tell me what I'm doing wrong?

Many thanks in advance for any help or advice.

Hugo Elias

 

[Ross A. Finlayson]

Hi all,

I have been kind of forced (honestly) into writing a class structure
which contains a Diamond of Death, and I'm not entirely sure what to
do about it.

I don't understand. Having a common virtual base class is sometimes an
appropriate design. Why do you call it a "Diamond of Death"?

This is a simplified version of my class structure:

Simplified to the point of incorrectness, since the code in main (that's
what _tmain means, right?) refers to ENTITY but the nearest thing here
is entity.

class entity
{
public:
entity() {}

int a;
};


class item : public entity
{
public:
item() {}

int b;
};


class loop : public virtual item
{
public:
loop() {}

int c;
};


class path : public virtual item
{
public:
path() {}

int d;
};

class test : public path, public loop
{
public:
test() {}

int e;
};



int _tmain(int argc, _TCHAR* argv[])
{
ENTITY *entity_test = new test();
ENTITY *entity_loop = new loop();

loop* l = (loop*)entity_loop; // cannot convert a 'ENTITY*' to a
'loop*'
// conversion from a virtual base
class is implied

You need to use dynamic_cast here, and in order to do that, ENTITY or
entity, whichever is the real class, needs to have at least one virtual
function.

There are different ways to do it, C++ has a way, without resorting to
lower level languages with the platform runtime.

It is in the C++ FAQ how to deal with the dreaded diamond, I suggest you
read it.

http://www.parashift.com/c++-faq-lite/
http://www.google.com/search?q=diamond&sitesearch=www.parashift.com

In the C++ there is the virtual keyword in the application of the
reinheritance and so on. It defaults the class body's inherited method
from the common ancestor class, they can be casted among the
intermediate types.

Thanks,

Ross F.

 

[Hugo Elias]

I don't understand. Having a common virtual base class is sometimes an
appropriate design. Why do you call it a "Diamond of Death"?

I didn't know it had another name. What do you call it?

Simplified to the point of incorrectness, since the code in main (that's
what _tmain means, right?) refers to ENTITY but the nearest thing here
is entity.

Whoops! I was just editing it to make it look nicer for the post,
but obviously missed that.

You need to use dynamic_cast here, and in order to do that, ENTITY or
entity, whichever is the real class, needs to have at least one virtual
function.

Thanks Pete! That seems to work now. I'll try it out on the proper code
when I get home.

Many thanks

Hugo

 

[Juha Nieminen]

Because proponents of languages that don't support multiple inheritance
properly have gone out of their way to convince everyone how terrible it
is. This is always a frustrating discussion; nobody can tell you *why*
it's bad, but they're sure it's a bomb waiting to go off. No exceptions.

Another irritating thing is that because of the "dangers" of diamond
inheritance, these languages forbid multiple inheritance.

Why the heck do they have to forbid multiple inheritance in order to
avoid diamond inheritance? Why not forbid diamond inheritance only?
There are tons of situations where non-diamond multiple inheritance
would be extremely useful, but these languages go ahead and remove this
useful object-oriented tool.

 

[Hugo Elias]

Why the heck do they have to forbid multiple inheritance in order to
avoid diamond inheritance? Why not forbid diamond inheritance only?
There are tons of situations where non-diamond multiple inheritance
would be extremely useful, but these languages go ahead and remove this
useful object-oriented tool.

That's what I've always wondered! MI is totally useful.

Hugo

 

[Juha Nieminen]

I suspect that they avoid MI because of difficulty implementing it,
rather than difficulty using it.

Is it really so difficult to implement multiple inheritance in a
language and its compilers?

I do understand that diamond inheritance (what C++ implements as
virtual inheritance) can become complicated. However, what makes
multiple inheritance complicated?

And in this context when I say "complicated" I don't mean "it requires
n thousands of complex code to implement compiler support". That's just
technical detail. With "complicated" I mean eg. situations which are
ambiguous and there's no clear "best solution". An example of what I
consider "complicated" is exception throwing (and subsequent stack
unwinding) in C++: This is a very complicated issue, and there is no
clear "best solution" (afaik all solutions have their own little
problems, often related to efficiency and/or code size).

 

[James Kanze]

Is it really so difficult to implement multiple inheritance in
a language and its compilers?

I do understand that diamond inheritance (what C++ implements
as virtual inheritance) can become complicated. However, what
makes multiple inheritance complicated?

Well, multiple inheritance without virtual base classes is
pretty useless. Practically speaking, if you support multiple
inheritance, virtual inheritance should almost be the default.

I think multiple inheritance may have gotten a bad name because
virtual inheritance wasn't the default. The diamond pattern
works perfectly well; having multiple instances of the same base
class can cause serious problems. The only real problem with
the diamond pattern in C++ is knowing where to put the virtual
keywords---if inheritance were virtual by default, that problem
would disappear. (There was also a bug in early CFront
implementations which meant that virtual inheritance resulted in
outrageously large classes. Which gave virtual inheritance a
bad name in memory tight situations.)

Another reason some people opposed (and perhaps still oppose)
multiple inheritance is because Smalltalk didn't have it. But
Smalltalk didn't have inheritance of interface, in the sense we
think of it in C++: it didn't require an interface to be
declared, and you could call any possible function on any object
(and get a runtime error if the object didn't support that
function). With static type checking, multiple inheritance
(using the equivalent of virtual inheritance) is practically a
necessity, and all of the OO languages I know with static type
checking support it. (Of course, that's not very many: C++ and
Java.)

 

[Juha Nieminen]

Well, multiple inheritance without virtual base classes is
pretty useless. Practically speaking, if you support multiple
inheritance, virtual inheritance should almost be the default.

Virtual inheritance is only needed for diamond inheritance situations.
What do you need virtual inheritance for when there's no diamond
inheritance?

 

[James Kanze]

Virtual inheritance is only needed for diamond inheritance
situations. What do you need virtual inheritance for when
there's no diamond inheritance?

And when is that?

The problem is that technically, the compiler needs to decide
which type of inheritance to use before the final pattern is
known. And since multiple inheritance implies that the diamond
pattern will be needed for some scenarios involving further
inheritance, you need to inherit virtually whenever you inherit
interfaces, e.g.:

class Interface { /* ... */ } ;
class ExtendedInterface : public Interface { /* ... */ } ;

Without virual inheritance, you have effectively forbidden
anyone else from defining a different ExtendedInterface which
extends Interface. At least, you've forbidden anyone from
implementing both of the extended interfaces using the same
implementation class. Which is, in the end, the first use of
multiple inheritance; having one class implement two (or more)
different interfaces.

Anytime you extend an interface, you should inherit virtually,
unless the complete hierarchy is closed and fully known.

Of course, most inheritance isn't very deep; you don't always
extend interfaces. But since virtual inheritance works in all
cases, and non-virtual fails in one major and important case,
virtual should be the default. (Which should be overridable in
those rare cases where you really want two instances of the same
base class.)

 

[James Kanze]

Disagreed. I use MI mostly for mixins. None of the classes
involved typically even have any virtual methods.

Then why bother with inheritance. If all function calls are
resolved at compile time, templates are generally a better
choice.

In practice, the largest single use of MI is for one
implementation class to implement several interfaces. It's true
that you don't need MI for this; you can always play games with
forwarding classes. But MI certainly makes it a lot easier.
(Note that this is the only use of MI that Java supports.) And
of course, if the interfaces you are implementing extend other
interfaces, then you need virtual inheritance. And since it
never hurts, why not make it the default?

 

[Juha Nieminen]

The problem is that technically, the compiler needs to decide
which type of inheritance to use before the final pattern is
known.

My point was that it's perfectly possible to support multiple
inheritance and forbid diamond inheritance at the same time (in a
hypothetical OO language, that is). MI is extremely useful even without
support for diamond inheritance.