Re: On C++ multiple inheritance

[Pascal Maillard <poizon@xxxxxx>]

Hi Miguel,

I believe Christian is right on some extend. There are many good features in 
programming languages that can be very helpful, but can be used to produce 
bad, buggy code (think of goto). If I wrote a book about, for example, C, I 
wouldn't write "goto is a cool feature", because then I'll get tons of mails 
from people blaming me for their spaghetti-code. The point is, if you believe 
that you and the people in your team are competent enough to unterstand code 
that uses multiple inheritance, use it.

However, I want to recommend you 2 things:

1. Using multiple inheritance to define an interface a class shall support (by 
inheriting from a class that contains only pure abstract methods) is harmless 
and very useful. This corresponds to Java "interfaces", which are known to 
work well. If you want to see this technique applied in C++, look at the KDE 
code, they use it a lot.

2. If the superclass you inherit from does not contain only pure abstract 
functions, then you should avoid having cycles in your inheritance graph. 
This situation

        supersuperclass
  superclass1    superclass2
           subclass

(that is: subclass inherits from superclass1 and superclass2, which both 
inherit from supersuperclass) can be error prone if superclass1 and 
superclass2 access members from supersuperclass. But again, if you specify 
clear constrains to work around this, use it. But I'd first try to find a 
design that doesn't have to use this feature.

I hope I could help you.

cö,
Pascal

Am Donnerstag, 14. April 2005 21:12 schrieb Miguel A. Osorio:
> Hey people,
>
>
>  I'm currently in the process of doing some changes to my renderer and
> I'll probably adding some new classes into the existing hierarchy. At
> this time, I do make some *light* use of multiple inheritance and
> haven't had any problems with it yet, nor do I detect any problems
> arising from changes or additions I'll be making to the hierarchy.
>
>  *But*, I have noticed that quite a large number of programmers declare
> multiple inheritance as something to be "avoided like the plague", and
> although I can relate to that if I imagine a badly designed hierarchy
> using that mechanism, I'm not really sure of the reasons behind negative
> arguments like that.
>
> 	I'd like to know your opinions on this, since at this point I can still
> re-design my current hierarchy to make use of single inheritance only,
> though I still fear that possibly weak decisions on the revised
> architechture might jump up in the future and bite me :P.
>
> 	I'd like to make it clear that the current implementation makes only
> slight use of multiple inheritance, and the future one, with
> modifications and additions, and which is already planned, still uses
> the mechanism only slightly. So, would that be acceptable, or should I
> just go ahead and use single inheritance exclusively?
>
> 	Thing is, the switch to exclusive-single-inheritance-mode can be made,
> as I said, but it'll break some of the semantics for some existing
> classes, which kind of annoys me. I'm afaid that in doing that I might
> have to settle for "strange" things such as for example: a class that
> defines the concept of a positionable and orientable object deriving
> from a class that defines a rendering primitive which has a material ID.
> That relation is not necessarily true in some cases, which kind of puts
> the whole architechture in perspective, huh?
>
>
>
> Thanks for your time,
> M.