#### Archived

This topic is now archived and is closed to further replies.

# when is multiple inheritance bad?

This topic is 5601 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

i have a few classes that inherit from multiple classes. one is a ogg vorbis class that inherits from a resource class that all my loaded objects derive from. the other thing it inherits from is a thread class for looping in the background. is this bad? if not, what is? [edited by - billybob on January 21, 2003 9:22:25 PM]

##### Share on other sites
There are several reasons to avoid MI, but if you do use it always try to avoid a diamond-shaped inheritance hierarcy. In your example, I would probably privately inherit from the thread class or maybe have a thread object attribute.

 Doesnt your sound library do the required threading for you anyway?

[edited by - sark on January 21, 2003 12:57:40 AM]

##### Share on other sites
nope, its openal, so it has to periodically update to queue more buffers with the music data before it runs out.

diamond shaped?

##### Share on other sites
quote:
Original post by billybob
diamond shaped?

A diamond-shaped inheritance hierarchy looks like this:

     A    / \   B   C    \ /     D

Where A is the root base class and D is at the top of the hierarchy. This can cause ambiguity problems. I dont remember the specifics, but diamond shapes are a pain in the arse and can almost always be avoided.

##### Share on other sites
the problem occurs when B and C have a function named the same thing that takes the same parameters. Incredibly nasty stuff happens (sometimes compile errors, sometimes runtime errors)...

I have yet to see a nastier-to-trace bug than one I had with diamond inheritance...

##### Share on other sites
quote:
Original post by xaxa

You need it when you have pure virtual baseclasses representing "interfaces" in C++, something which is used quite a bit in C++ OO methodology.

##### Share on other sites
oh, these are just really simple classes. CResource is the base class for anything that is loaded from a file, has a 32 bit id number, file name, type, and stuff like that. it doesn''t inherit from anything. the thread class is just a simple thread, it has like 3 public functions, doesn''t inherit from anything. so i take it this is safe

##### Share on other sites
quote:
always try to avoid a diamond-shaped inheritance hierarcy

Diamond shaped is sometimes a great solution. I used to oppose it too but then I stumbled across a problem that could be perfectly solved with it. The hierarchy looked like this:
      A     /|\    / | \   B  C  D   | /|\ |   |/ | \|   E  F  G   | / \ |    |/   \|     H     I

It was actually quite a bit more complex but I drew the simplified version.

The only other solution I came up for the problem I had was to use the bridge pattern. But bridge was hugely more bloated and didn''t add any benefits, so why would I fanatically oppose weird looking multiple inheritance if it happens to be the most suitable solution?-)

##### Share on other sites
quote:
Original post by billybob

When is inheritance bad? Inheritance is a mechanism for sharing commonality across multiple classes. In static languages like C++, it is also a means of allowing the compiler to verify the IS-A relationship at compile-time, so that inheritance means two things in C++: it is a code-sharing (mix-in) mechanism, and it is a means of re-introducing some limited amount of polymorphism into a language which enforces non-polymorphism as the default. Problems occur when these two concerns get confused. For example, people inherit a base class in order to mix-in some common code, and then find they have a meaningless "IS-A" relationship. Often, it is better to attempt aggregation / delegation before resorting to inheritance, although C++ does not do delegation well either. See: C++ Support for Delegation. However, although delegation can involve a lot of code replication, it does avoid the confused semantics of inheritance, which is potentially a bigger problem.

Multiple inheritance introduces yet another problem. Adding to the confusion of inheritance serving two concerns, in C++ classes also serve a dual role: they are both the building block of the object system and a namespace for resolving the meaning of symbols. When multiply-inheriting two classes, the symbol-tables clash together. With no means of determining precedence, this potentially creates naming conflicts. Further code replication is then required to disambiguate the conflicts. Nice, huh?
quote:

i have a few classes that inherit from multiple classes. one is a ogg vorbis class that inherits from a resource class that all my loaded objects derive from. the other thing it inherits from is a thread class for looping in the background. is this bad?

The odds say "yes", but your description is insufficient to tell for sure.

[edited by - SabreMan on January 22, 2003 9:10:06 AM]

• 9
• 16
• 9
• 13
• 41