[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: On C++ multiple inheritance
Pascal Maillard wrote:
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.
(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
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!" :).