advice on programming style: is multiple inheritance bad?

[Roy Smith]

Uwe Mayer <merkosh at hadiko.de> wrote:
> On a lecture on software engeneering I was tought that multiple 
> inheritance was a bad thing to do, since there are problems with the 
> resolution order which leads to badly readable code, induces errors, 
> shows poor software design, etc.

There are certainly problems with multiple inheritance, but that doesn't 
mean that all uses of MI are inherently evil.  It is certainly 
worthwhile to listen to the arguments the anti-MI people make and think 
about the problems.

Of course, you need to be able to factor out those arguments which are 
language-specific from those which are more general.

> When writing the sentence above I was implying that m.i. in C++ propably is
> difficult to handle

Everything in C++ is difficult to handle.  I don't see anything about 
C++'s MI implementation which stands out as particularly worse or more 
complex than the rest of the class inheritance system.
 
> How much effort is it worth to keep up good transparent programming design
> at cost of more code, more levels of delegation (slower) and a more complex
> interior in general?

That's a complicated question, and I'm not sure I fully understand what 
you're asking, but my general answer would be that your main goal should 
be to make the program easy for somebody else to understand (perhaps 
years from now, when you're no longer around to answer questions).  The 
number of lines of code is secondary, and speed of execution even less 
important.

When the whole thing is done, and you're sure everything works, that's 
the time to figure out if it's fast enough.  If it's not, then you 
should start profiling things to figure out where most of the time is 
being spent and look there for speedups.  The biggest speedups will 
typically come from algorithmic improvements, not from low-level 
optimizations like using or not using MI.