Dangers of Multiple Inheritance

[Corno]

Hi all,

I know there are quite a few arguments in favor or against MI. I know there
are a lot of usenet discussions about wether MI is actually needed or not.
These discussions mention the 'dangers' of MI.
The problem is; I know that there are dangers concerned with MI and I know
how I can avoid them, I just don't have a clear idea of what the dangers
actually are and if they are applicable to to the situations I encounter.
The only danger I (think I) really understand is the dreaded diamond.
But there also seems to be an issue with copying and assignment which I
don't see.
And is there more danger that I should be aware of? and will these problems
surface during compiling or runtime?

Does anybody know a good article specifically about this or else would
somebody care to explain it to me in this newsgroup?

TIA,

Corno

[Michel de Becdelièvre]

Re: Dangers of Multiple Inheritance

"Corno" <corno@%spam%.d ds.nl> a écrit dans le message de
news:bkpcqk$1mj $1@news.tudelft .nl...[color=blue]
> And is there more danger that I should be aware of? and will these[/color]
problems[color=blue]
> surface during compiling or runtime?[/color]

It is at least partially a case of saying it is dangerous to avoid having to
implement it in many GC based languages.
It apparently makes building an efficient GC more difficult to design (not
impossible, see Eiffel).
So Java & C# designer replaced it with interfaces (multiple inheritance
without data) as a workaround.

[David B. Held]

Re: Dangers of Multiple Inheritance

"Corno" <corno@%spam%.d ds.nl> wrote in message
news:bkpcqk$1mj $1@news.tudelft .nl...[color=blue]
>
> I know there are quite a few arguments in favor or against MI. I
> know there are a lot of usenet discussions about wether MI is
> actually needed or not.[/color]

MI is "not needed" in the way that classes "aren't needed". That is,
you can write equivalent programs without it, but the feature makes
some designs a lot simpler.
[color=blue]
> [...]
> The only danger I (think I) really understand is the dreaded
> diamond.[/color]

LOL@"dreaded" The diamond inheritance diagram strikes fear in
the hearts of coders!
[color=blue]
> But there also seems to be an issue with copying and assignment
> which I don't see.[/color]

I don't see it either. You have to make sure that all your base
classes agree on how to copy and assign, but I'm not aware of any
nasty gotchas.
[color=blue]
> And is there more danger that I should be aware of? and will these
> problems surface during compiling or runtime?[/color]

One issue to keep in mind is size. Many, if not most compilers will
make your derived class much bigger than it would be if you did
not use MI (but rather used a chained approach). There is a solution
for this, but it's a little tricky, and has its own set of issues.
[color=blue]
> Does anybody know a good article specifically about this or else
> would somebody care to explain it to me in this newsgroup?[/color]

An interesting discussion to check out would be on the Boost
developer list. You can find the archives on Google. The thread
is about Loki::SmartPtr, which uses MI in a big and obvious way.
Quite a few issues relating to MI came up in that discussion. Look
for 'SmartPtr' and 'MI'.

Dave