What are the disadvantages of using multiple inheritance to implement components?

Question

I've been doing research on component-based game engines and would like to use that model for future game projects. From what I gather, objects in a component-based system are just collections of attributes and behaviors. The examples I've seen have a high-level interface such as Attribute<T> *Entity::getAttribute<T>(int id) but discussions about those systems often talk about performance problems. It seems like this could be implemented with greater efficiency in C++ using multiple virtual inheritance since the compiler could inline attribute accesses and behavior method calls:

// Layer 1: Base
struct Entity {
  virtual ~Entity() {}
  virtual void draw() {}
  virtual void update(float seconds) {}
};

// Layer 2: Attributes each extend from Entity
struct Position : virtual Entity { Vector3 pos; };
struct Velocity : virtual Entity { Vector3 vel; };
struct Health : virtual Entity { int health; };
struct Target : virtual Entity { Position *target; };

// Layer 3: Behaviors extend from the attributes they need
struct Renders : virtual Position {
  Model model;
  void draw() { model.draw(); }
};
struct Moves : virtual Position, virtual Velocity {
  void update(float seconds) { pos += vel * seconds; }
};
struct Seeks : virtual Moves, virtual Target {
  void update(float seconds) {
    if (target) vel = (target->pos - pos).unit();
    Moves::update(seconds);
  }
};

// Layer 4: Definitions extend from the behaviors they need
struct Rocket : virtual Health, virtual Renders, virtual Seeks {};

However, many component-based engine resources discount multiple inheritance without really saying why. I'm sure I'm missing something, but what are the disadvantages of using multiple inheritance like this over lists of components? I know calls to base classes when using multiple inheritance incur an additional constant offset, but that seems better than going through a run-time map for each attribute access. The only disadvantage that I can think of is not being able to swap out components at run-time.

Resources:

• http://www.gdcvault.com/play/1911/ (PPT)
• http://www.richardlord.net/blog/what-is-an-entity-framework

Answer 1

Well, you pointed out The Big Disadvantage yourself:

The only disadvantage that I can think of is not being able to swap out components at run-time.

Its direct consequence makes it a no-go... One of the most interesting feature of a component-based system is that it can be data-driven. By using inheritance, creating a new entity kind means a recompile. Compiling can be, very, very long. And worse, you're limiting that to programmers only.

Gajet gave some other valid points too, but to me that's the #1 problem with the approach you expose.

A detail: I've hardly ever seen virtual inheritance used in a game engine. It might be plain ignorance/laziness, or maybe there's never a good reason to use it, but I also suspect poor compiler support on consoles.

Answer 2

I can think of one or two reasons but I don't think they are not solid proof:

1. Using multiple inheritance as extensive at what you explained could easily get out of control. I know at first it seems it may help you along the way, but with a simple mistake you might end up with a bunch of code that generates a run-time error; Which you can't track down.
2. The whole multiple inheritance thing is based on too many memory jumps before calling each function. the same goes for each data lookup. So later when you need a high performance structure to do everything neat and fast you might end up with bunch of slow codes not allowing you to add any features.
3. Keeping the code simple is always the best strategy against large code bases. And games (specially in engine part) always end up having a large amount of code.
4. Though this might be the stupidest thing you've ever heard but working with an structure will lead somehow to being used to that structure. for example a person who works with C# almost always have a hard time switching to Java, though their syntax is very likely. I'm not saying he can't but he'll keep nagging about how good C# was and how bad Java is. multiple inheritance is something just a few languages implemented, so by using it you might later have a hard time switching to other languages.
5. With the exact same reason other languages doesn't support multiple inheritance yo might later get into trouble when porting your game to other languages. If you use common tools, you'll only need to change syntax while converting. But using multiple inheritance you need to convert the whole implantation method which takes as much time as writing a new code from scratch.

All that said I also think it would be nice if someone try that once and tell if he had a good experience with that kind of design. But you know existing mostly used structures are proved through the ages that can do any thing you want them to, so why do you want to change these well-proved mechanisms?