Polymorphism

This lesson is a quick introductory tour of polymorphism within C++. It is not intended for those who are entirely new to programming. Rather, the people who may find it useful include:

• those who have completed our introductory course, but want a quick review
• those who are already familiar with programming in another language, but new to C++
• those who have used C++ in the past, but would benefit from a refresher

It summarises several lessons from our introductory course. Anyone looking for more thorough explanations or additional context should consider Chapter 6 of that course.

Previous Course

Intro to Programming with C++

Starting from the fundamentals, become a C++ software engineer, step by step.

View Course

Early Binding

When calling methods through references and pointers, C++ uses early binding by default. That means, the compiler figures out what methods to call at compile time, based on the type of reference or pointer:

1#include <iostream>
2
3class Monster {
4public:
5  void Log(){ std::cout << "Monster\n"; }
6};
7
8class Dragon : public Base {
9public:
10  void Log(){ std::cout << "Dragon\n"; }
11};
12
13void CallMethod(Base& Object){ Object.Log(); }
14
15int main(){
16  Monster BaseObject;
17  std::cout << "The first object is a ";
18  CallMethod(BaseObject);
19
20  Dragon DerivedObject;
21  std::cout << "The second object is a ";
22  CallMethod(DerivedObject);
23}
24

1The first object is a Monster
2The second object is a Monster
3

The output is technically correct, but perhaps not what we were expecting or wanted. The second object is a Monster, but it is specifically a Dragon.

Even though the second invocation of CallMethod is passed a reference to a Dragon object, our program logs Monster both times.

This is because the reference in the CallMethod function has the type of Monster, and the Monster::Log function uses early binding. Early binding means the compiler identifies what function to call at compile time, based on the specific type of the object.

In this case, the type within the CallMethod function was a Monster object, so the compiler binds the Object.Log() call to the version of that function that is in the Monster class.

Late Binding with virtual

To flag a method for late binding, we need to add the virtual specifier to it:

1class Monster {
2public:
3  virtual void Log(){ std::cout << "Monster\n"; }
4};
5

This has performance implications, as our program now needs to find the correct function at run time.

But, because it happens at run time, our program can investigate exactly what is stored in that location in memory at the point our function is called. It identifies the second call as receiving not just a plain old Monster object, but specifically a Dragon object.

As a result, it calls the more specific function, which was in the Dragon class. With no further changes to our program, we get the desired output:

1The first object is a Monster
2The second object is a Dragon
3

This is an example of a powerful run-time polymorphism a powerful concept that lets our project expand in complexity, without our systems getting more complex.

Our core systems (in this case, the contrived CallMethod() function) haven’t changed. In fact, those systems don’t even know there is a class called Dragon. Yet, they can interact with Dragon objects, invoking all the dragon-specific behaviors.

We could add 100 more types of Monster, and our core systems don’t need to change at all to accommodate all that variation. They just call Monster methods, and our specific Monster subtypes get to decide what happens, by overriding those methods as required.

The override keyword

When a child class is overriding a function it is inheriting, we should add the override specifier to that function:

1class Dragon : public Monster {
2public:
3  void Log() override {
4    std::cout << "Dragon" << endl;
5  }
6};
7

This is optional, but highly recommended. Adding the override specifier makes our intent clear, both to other developers and the compiler.

If we attempt to override a function, but we misspell its name, or provide a different argument list, the compiler doesn’t know we’ve made a mistake. It assumes we’re just defining a different function, so it lets the bug slip through.

By adding the override specifier, the compiler will know our intent and will throw an error if the function we’re defining on the derived class is not actually overriding anything on a base class.

Downcasting with dynamic_cast

When we have a pointer or reference of the base type, and we want to access a function or variable on a more derived type, we can use dynamic_cast:

In this method, we have a parameter of the type Monster&, but we suspect it might be a more specific Dragon object, so we downcast it appropriately:

1void CallMethod(Monster& Object) {
2  dynamic_cast<Dragon&>(Object);
3}
4

To use dynamic_cast, our type must be polymorphic, that is, it must define at least one virtual method. If we otherwise have no need for any virtual method in the class, conventionally we just mark the destructor as virtual:

1class Monster {
2public:
3  virtual ~Monster(){}
4};
5

Dynamic casting will succeed if the reference or pointer really is the derived type we tried to cast it to. In that successful scenario, it will return a reference or pointer to that same memory location, but with an updated type. This allows us to access derived members:

1#include <iostream>
2
3class Monster {
4public:
5  virtual void BaseFunction(){
6    std::cout << "Monster ";
7  }
8};
9
10class Dragon : public Monster {
11public:
12  void DerivedFunction(){
13    std::cout << "and Dragon";
14  }
15};
16
17void CallMethod(Monster& Obj){
18  Obj.BaseFunction();
19  dynamic_cast<Dragon&>(Obj).DerivedFunction();
20}
21
22int main(){
23  Dragon DerivedObject;
24  CallMethod(DerivedObject);
25}
26

1Monster and Dragon
2

Dynamic casting can fail. This happens when the object doesn’t actually have the type we’re trying to cast it to. Below, we’re trying to dynamic cast to a Dragon, but what we’ve received is just a plain old Monster:

1void CallMethod(Monster& Object) {
2  dynamic_cast<Dragon&>(Object);
3}
4
5int main() {
6  Monster BaseObject;
7  CallMethod(BaseObject);
8}
9

If dynamic casting a reference fails, as in the above example, our code will throw an exception. We cover exceptions and how to handle them later in this course.

If dynamic casting a pointer fails, it returns a nullptr. We can test for null pointers by using an if statement:

1#include <iostream>
2
3class Monster {
4public:
5  virtual ~Monster(){}
6};
7
8class Dragon : public Monster {};
9
10void CallMethod(Monster* Obj){
11  Dragon* DragonPtr{dynamic_cast<Dragon*>(Obj)};
12  if (DragonPtr) {
13    std::cout << "That's a dragon\n";
14  } else {
15    std::cout << "That isn't";
16  }
17}
18
19int main(){
20  Dragon Scaly;
21  CallMethod(&Scaly);
22
23  Monster Goblin;
24  CallMethod(&Goblin);
25}
26

1That's a dragon
2That isn't
3