Dealing with a Diamond of Death
Rocketmagnet
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
Pete Becker
> 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.
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.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
Jeff Schwab
> On 2008-10-27 18:08:43 -0400, Rocketmagnet <hugo....@virgin.net> said:
>> 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"?
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.
In fairness, it is kind of nasty in some other languages. Python comes
to mind, because Python automatically breaks the diamond at run-time in
an unpleasant way.
Ross A. Finlayson
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.
Pete Becker
<r...@tiki-lounge.com.invalid> said:
Thanks for the pointer, but I'm quite familiar with virtual inheritance.
Hugo Elias
> On 2008-10-27 18:08:43 -0400, Rocketmagnet <hugo....@virgin.net> said:
>
>> 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"?
I didn't know it had another name. What do you call it?
>> 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.
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.
Jeff Schwab
I suspect that they avoid MI because of difficulty implementing it,
rather than difficulty using it. Then there has to be a sour grapes
pitch by the language proponents, explaining why you didn't really want
that feature, anyway.
Pete Becker
> Juha Nieminen wrote:
>> Jeff Schwab wrote:
>>> 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.
>
> I suspect that they avoid MI because of difficulty implementing it,
> rather than difficulty using it.
No, it's because Barbie says "multiple inheritance is hard!"
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
>> 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.
>
> 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).
blargg
<je...@schwabcenter.com> wrote:
One of the other rather silly objections I've heard is that it allows
ambiguity where two base classes each have something named the same. Scope
resolution is too much to ask for, apparently. Oddly, this same objection
is why inherited:: wasn't added to C++, because it would be ambiguous when
a given name was in more than one base classes, even though in most cases
it wouldn't, and would be quite useful in the presence of MI. Oh well.
James Kanze
> Jeff Schwab wrote:
> >> 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.
> > 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?
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.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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?
Jeff Schwab
> On Oct 28, 11:52 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> Jeff Schwab wrote:
>>>> 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.
>
>>> 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?
>
> Well, multiple inheritance without virtual base classes is
> pretty useless. Practically speaking, if you support multiple
> inheritance, virtual inheritance should almost be the default.
Disagreed. I use MI mostly for mixins. None of the classes involved
typically even have any virtual methods.
James Kanze
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
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?
Pete Becker
>
> 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?
"Never hurts" is a bit too strong. It makes access to base elements a
bit slower, and it requires dynamic_cast for conversions that could be
done with static_cast when the base isn't virtual.
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.
Jeff Schwab
> On Oct 29, 6:47 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> James Kanze wrote:
>>> Well, multiple inheritance without virtual base classes is
>>> pretty useless. Practically speaking, if you support
>>> multiple inheritance, virtual inheritance should almost be
>>> the default.
>
>> 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.
Those aren't mutually exclusive. I particularly use Andrei's
policy-based design technique, in which the mixins are template
parameters. To tell you the truth, I never really understood what
mixins were (much less what they were good for) until I read Modern C++
Design. I had seen references in passing, e.g. in TC++PL, but didn't
appreciate the potential until I started seeing classes derived from
types provided as template arguments. Of course, MI is also good (as
you suggest) for letting a single type implement multiple interfaces of
the pure-virtual variety. In this sense, "public virtual" is roughly
analogous to Java's "implements" (or "extends", if the derived type is
also just an interface).