[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: On C++ multiple inheritance

Pascal Maillard wrote: 
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.

Yeah, I agree. But then again, I don't know if this is the case, but I didn't want to leave the impression that I use, or would continue to use, multiple inheritance, for example, just because it's there in the language and all. I stongly believe in programmer competence, and personaly prefer languages that put you in control of things as opposed to try to "shield" itself against the programmer. At the same time, I also strongly object using feature X or Y just because it's "cool" or something, without a clear picture of why, when and how.

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.

Ok, I see the point. In the current design, and where it's headed, I try really hard to isolate certain concepts as classes as much as possible. That is especially true with classes that end up creating multiple inheritance situations. Except for some particle system code, I don't use pure abstract classes much, but as I said, each class does try to isolate functionality as much as possible.
So in that aspect, I would consider myself to currently be on the "safe" side of things, but I did put this into discussion because, since I hardly consider myself a "master" programmer (more or less as good, but not that good :P), I'd like some help in looking at the bigger picture first, before making potentially weak design decisions.
Then again, I got the message on some possible pitfalls with multiple inheritance, and I also intend to RTFM (in this case, the classic reference "The C++ Programming Language") again too, and attempt to clarify the situation further.
As I said, the only problem I'm running into when trying to flatten the hierarchy into a single-inheritance-only design, is that some concepts which are very clear to me end up breaking a bit and start making not so much sense when coupled with other concepts that must now be part of the architechture too.

I hope I could help you.

Yes, thank you very much, and I also thank the others for their opinions too. I believe the final message here is, well, "if you feel you're competent enough, and the problem actualy requires it, then go ahead and use it. And if something does break, don't go running around yelling it's other peoples faults!" :).


[]s,
M.