By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,538 Members | 875 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,538 IT Pros & Developers. It's quick & easy.

Dealing with a Diamond of Death

P: n/a
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
Oct 27 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Pete Becker wrote:
On 2008-10-27 18:08:43 -0400, Rocketmagnet <hu********@virgin.netsaid:
>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.
Oct 27 '08 #2

P: n/a
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.
Virtual inheritance is only needed for diamond inheritance situations.
What do you need virtual inheritance for when there's no diamond
inheritance?
Oct 29 '08 #3

P: n/a
On Oct 29, 4:33 pm, Juha Nieminen <nos...@thanks.invalidwrote:
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.
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 (GABI Software) email:ja*********@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
Oct 30 '08 #4

P: n/a
On 2008-10-30 06:06:12 -0400, James Kanze <ja*********@gmail.comsaid:
>
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.

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

Oct 30 '08 #5

P: n/a
James Kanze wrote:
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.
Oct 30 '08 #6

P: n/a
James Kanze wrote:
On Oct 29, 6:47 pm, Jeff Schwab <j...@schwabcenter.comwrote:
>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).
Oct 30 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.