Does dynamic_cast really work for multiple inheritance?

Question

I wanted to see if it's possible to create "interfaces", inherit them, and then check at runtime if any random class implements that interface. This is what I have:

struct GameObject {
    int x,y;
    std::string name;

    virtual void blah() { };
};

struct Airholder {
   int oxygen;
   int nitrogen;
};

struct Turf : public GameObject, public Airholder {
   Turf() : GameObject() {
      name = "Turf";
   }

   void blah() { };
};

void remove_air(GameObject* o) {
   Airholder* a = dynamic_cast<Airholder*>(o);
   if(!a) return;
   a->oxygen   = 0;
   a->nitrogen = 0;
};

Now, it works. The documentation says that it works, the test example works.. But also, it didn't compile until I added a virtual method to GameObject. The thing is, I really don't know if the feature is intended to be used like that. What made me wonder there is the fact that I have to declare a virtual function for the class I'm checking. But obviously, there is none, the class I'm checking itself has no virtual functions, in fact my whole code has nothing to do with virtual functions, it's an entirely different approach.

So, I guess my question is: If what I'm doing really works, why do I need a virtual function to give my class a vtable? Why can't I declare the class a "runtime type" or something without virtual functions?

Answer 1

§ 5.2.7 of the standard says:

1. The result of the expression dynamic_cast(v) is the result of converting the expression v to type T. T shall be a pointer or reference to a complete class type, or “pointer to cv void”. Types shall not be defined in a dynamic_cast. The dynamic_cast operator shall not cast away constness (5.2.11).
2. If T is a pointer type, v shall be an rvalue of a pointer to complete class type, and the result is an rvalue of type T. If T is a reference type, v shall be an lvalue of a complete class type, and the result is an lvalue of the type referred to by T.
3. If the type of v is the same as the required result type (which, for convenience, will be called R in this description), or it is the same as R except that the class object type in R is more cv-qualified than the class object type in v, the result is v (converted if necessary).
4. If the value of v is a null pointer value in the pointer case, the result is the null pointer value of type R.

5. If T is “pointer to cv1 B” and v has type “pointer to cv2 D” such that B is a base class of D, the result is a pointer to the unique B sub-object of the D object pointed to by v. Similarly, if T is “reference to cv1 B” and v has type “cv2 D” such that B is a base class of D, the result is an lvalue for the unique60) B sub-object of the D object referred to by v. In both the pointer and reference cases, cv1 shall be the same cvqualification as, or greater cv-qualification than, cv2, and B shall be an accessible unambiguous base class of D. [Example:

   struct B {};
   struct D : B {};
   void foo(D* dp)
   {
        B* bp = dynamic_cast(dp); // equivalent to B* bp = dp;
   }
   —end example]

6. Otherwise, v shall be a pointer to or an lvalue of a polymorphic type (10.3).

And to make a type polymorphic, it needs a virtual function, as per § 10.3:

Virtual functions support dynamic binding and object-oriented programming. A class that declares or inherits a virtual function is called a polymorphic class.

So the reason why is "because the standard says so." That doesn't really tell you why the standard says so though, but the other answers cover that well I think.

Answer 2

So, I guess my question is: If what I'm doing really works, why do I need a virtual function to give my class a vtable? Why can't I declare the class a "runtime type" or something without virtual functions?

The presence of a virtual function is what makes a class polymorphic in C++. dynamic_cast<> only works with polymorphic classes. (The compiler will reject a dynamic cast on a non-polymorphic object.)

Polymorphism has a cost, both in time and in space (memory). Calls to virtual functions are now indirect, typically implemented in terms of a virtual table. In some critical places, those costs are simply unacceptable. So the language provides means of avoiding these costs.

Similar concepts exist elsewhere in the language. The underlying principle is that if you don't want to use some high-falutin' feature you shouldn't have to pay for the fact the some people do want to use it.