Virtual Functions and Overrides

Before we introduce the next topic, let's take some time to explain the goal.

Ambitious projects can have a lot of systems, and those systems manage complex interactions between objects.

Those systems also often need to support different types of objects, each of which can behave in slightly different ways.

In the context of a game, for example, that might include:

• lots of enemy types to fight in our combat system
• lots of quests to do in our questing system
• lots of items to select from for our equipment system

We need ways to implement all this complexity, without our code getting so complex it becomes unmanageable.

An Example Use Case

Let's take our hypothetical combat system. We want our game to support a large range of enemy types, each being capable of having their unique ways of fighting.

Goblins might charge in and attack at close range. Archers might stand back and fight from range. Dragons might take to the skies.

We don't want to define all those behaviors within the combat system. That would cause the system to get unmanagably complex, and more complex with every new enemy type we add.

Instead, our project is much more manageable if we encapsulate those behaviors within the respective classes. Our dragons’ behaviors should be in the Dragon class, goblin logic belongs in the Goblin class, and so on.

Run Time Polymorphism

In our hypothetical system, the player can run around and choose what enemies to battle with. Therefore, every time our combat system gets used, we don’t necessarily know the types that will be involved.

That is determined by player actions, at run time. Maybe the player will fight some goblins first, or maybe they’ll go for the dragon. So, we need run time polymorphism.

In C++, this is achieved by a combination of three techniques, two of which we’re already familiar with:

• Inheritance
• References and Pointers
• Virtual Functions

Let's see how we might combine these concepts to create the essence of a polymorphic combat system

Step 1: Inheritance

The first step of the process is establishing a base class, from which all of our combat participants will inherit. Here, we’ll call our base class Character, and we’ll provide an Act() function, which will represent a combat action.

Any time we want our character to do something, we’ll call Act(), and we’ll pass in a pointer to the target that our character is fighting:

1class Character {
2public:
3  void Act(Character* Target) {
4    cout << "Character Acting\n";
5  }
6};

Then, every type of object that we want to be able to participate in our combat system, such as goblins and dragons, will inherit from this base class:

1class Character {
2public:
3  void Act(Character* Target) {
4    cout << "Character Acting\n";
5  }
6};
7
8class Goblin : public Character {};
9
10class Dragon : public Character {};

Step 2: References and Pointers

For the next step, we set up our systems to work with references or pointers to this shared base type.

In this example, we’ll represent our combat system as a simple function called Battle. Battle receives two Character pointers, and has them Act() upon each other:

1void Battle(Character* A, Character* B) {
2  A->Act(B);
3  B->Act(A);
4}

Remember, under the rules of inheritance, Goblins and Dragons are Characters. So each of these pointers could be pointing at a basic Character, a Dragon, a Goblin, or any other subtype of Character we add in the future.

So far, so good. Below, a Goblin and a Dragon enter battle, and both of our combatants are using the Act() function defined on the basic Character class:

1#include <iostream>
2using namespace std;
3
4class Character {
5public:
6  void Act(Character* Target){
7    cout << "Character Acting\n";
8  }
9};
10
11class Goblin : public Character {};
12
13class Dragon : public Character {};
14
15void Battle(Character* A, Character* B){
16  A->Act(B);
17  B->Act(A);
18}
19
20int main(){
21  Goblin A;
22  Dragon B;
23  Battle(&A, &B);
24}

1Character Acting
2Character Acting

Step 3: Virtual Functions

We want function calls like A->Act() to have different effects, depending on which subtype of character A is pointing at. For example, if A is a Goblin, the effect of this function call will be different than if A were a Dragon.

To achieve this, we need to provide Goblin and Dragon-specific implementations of the Act() function, using the same prototype as Act() within the Character class.

This is referred to as overriding the function:

1class Goblin : public Character {
2public:
3  void Act(Character* Target){
4    cout << "Goblin Acting\n";
5  }
6};
7
8class Dragon : public Character {
9public:
10  void Act(Character* Target){
11    cout << "Dragon Acting\n";
12  }
13};

Then, we need to mark the Character version of this function as virtual. We cover the significance of the virtual keyword in the next section:

1class Character {
2public:
3  virtual void Act(Character* Target){
4    cout << "Character Acting\n";
5  }
6};

With everything in place, we’ve now achieved run-time polymorphism. Without changing any code in our Battle function, its behavior is now dynamic:

1#include <iostream>
2using namespace std;
3
4class Character {
5public:
6  virtual void Act(Character* Target){
7    cout << "Character Acting\n";
8  }
9};
10
11class Goblin : public Character {
12public:
13  void Act(Character* Target){
14    cout << "Goblin Acting\n";
15  }
16};
17
18class Dragon : public Character {
19public:
20  void Act(Character* Target){
21    cout << "Dragon Acting\n";
22  }
23};
24
25void Battle(Character* A, Character* B){
26  A->Act(B);
27  B->Act(A);
28}
29
30int main(){
31  Goblin A;
32  Dragon B;
33  Battle(&A, &B);
34}

1Goblin Acting
2Dragon Acting

Expanding the System

With the basic system in place, we’re now free to expand it as needed, whilst effectively managing the complexity.

We can add depth by expanding the core system - that is, by expanding the Character class and the Battle function. For example, we introduce the concept of alive and dead below, with battle continuing until one of our combatants is dead:

1class Character {
2public:
3  virtual void Act(Character* Target){
4    cout << "Character Acting\n";
5  }
6
7  bool GetIsAlive(){ return isAlive; }
8
9protected:
10  bool isAlive{true};
11};
12
13void Battle(Character* A, Character* B){
14  while (A->GetIsAlive() && B->GetIsAlive()) {
15    A->Act(B);
16    B->Act(A);
17  }
18}

We can add breadth by adding more and more enemy types, without our combat system getting more and more complex. Our types just inherit from Character and override functions as needed.

Remember, we can use multiple layers of inheritance if needed. Our types don’t always need to inherit from Character directly:

1class Character {};
2class Dragon : public Character {};
3class FireDragon : public Dragon {};
4class FrostDragon : public Dragon {};
5class StormDragon : public Dragon {};

This pattern keeps our project organized and manageable, even as we scale up to hundreds or even thousands of types.

Our source code file might get a little large, but in the next chapter, we’ll see how we can split our project across multiple files. This allows us to keep types in dedicated files like Dragon.cpp and Goblin.cpp, helping us keep things organized as our classes get larger and more powerful.

Static (Early) and Dynamic (Late) Binding

The inclusion of the virtual keyword in our class function changes calls to that function from being statically bound to being dynamically bound.

By default, C++ binds our function calls to the function definitions in our code at compile time. This is sometimes referred to as static binding, or early binding.

In other words, when the compiler sees an expression like A->Act(), it investigates the type of A. In our Battle function, A is a Character, so the compiler binds this call to the Act() function as defined within the Character class.

By adding the virtual specifier, we’re asking the compiler to take a different approach. When we call a virtual function, the compiler determines what specific type of object our pointer is pointing at.

It then calls the version of the function within that type. If that type doesn’t define it, we then search up the inheritance tree until we find the nearest ancestor that does.

This needs to be done at run time, so is referred to as dynamic binding, or late binding.

Dynamic binding has a small performance impact at run time, which is why it is not used by default. When we need a function to behave this way, we have to explicitly opt it in, by marking it as virtual

The override Specifier

When a class function is overriding a virtual method on a base class, it is considered an override.

When this is happening, we should be explicit, by marking the function with the override keyword:

1class Goblin : public Character {
2public:
3  void Attack() override {
4    cout << "Goblin Attacking!" << endl;
5  }
6};

This is not required, but we should use it where applicable. It has two benefits:

• It informs other developers reading our function that it is an override
• The compiler ensures that our function really is overriding something. That is, it ensures there is a virtual function on a base class with the same prototype.

This second point is especially useful when we come back to update our code in the future. If we change the name or parameters of a function, any child class that was overriding it no longer will be, because the prototype will now be different.

By adding the override specifier, the compiler will detect that issue, and alert us. This makes sure we know to update those child classes too, preventing any bugs.

Preventing Overrides using final

When our code encounters a virtual function, the process of traversing down the inheritance tree to find the most derived override effectively treats all intermediate functions as virtual, too.

This is the case whether they are marked as virtual or not. In scenarios where we don't want that to happen, we can mark the function as final.

Below, our Goblin class doesn’t want any subtypes from overriding Act(), so it marks it as final. When GoblinWarrior tries, the compiler generates an error:

1class Character {
2public:
3  virtual void Act(){} 
4};
5
6class Goblin : public Character {
7public:
8  void Act() final{} 
9};
10
11class GoblinWarrior : public Goblin {
12public:
13  void Act() override{} 
14};

1error:
2'Goblin::Act': function declared as 'final'
3cannot be overridden by 'GoblinWarrior::Act'

Slicing

It is worth noting that this form of run-time polymorphism only works when we’re passing our objects by reference or pointer.

The following code creates a Goblin object and then passes that object by value to a Character parameter:

1class Character {};
2
3class Goblin : public Character {
4 public:
5  int Damage{10};
6};
7
8void Battle(Character Enemy){
9  // Enemy is always a basic Character  
10}
11
12int main() {
13  Goblin Bonker;
14  Battle(Bonker);
15}

Within the Battle() function, Enemy is no longer a Goblin. It is simply a Character. An object of a subtype can be copied to an object of a base type, and that’s what has happened here.

Any subtype-specific variables, such as the Damage integer in this case, are simply discarded, leaving us with a plain old Character.

This scenario is sometimes referred to as slicing. There are legitimate use cases where we may want to do this, but it’s frequently a bug.

Summary

In this lesson, we explored the powerful concept of virtual functions and overrides, which are essential for implementing runtime polymorphism. Here are the key takeaways:

• Virtual Functions: Virtual functions enable runtime polymorphism, allowing subclasses to provide specific implementations for functions declared in a base class.
• Inheritance and Polymorphism: Using inheritance, we can create a hierarchy of classes where derived classes can override the behavior of base class functions.
• Override Keyword: The override keyword, while not mandatory, clarifies that a function is intended to override a base class function and ensures safety by enabling compiler checks.
• Final Specifier: The final specifier is used to prevent further overriding of a method in any subclass, ensuring that the function behavior remains consistent in the inheritance hierarchy.
• Object Slicing: We learned about object slicing, a phenomenon where a derived class object is treated as a base class object, leading to the potential loss of derived class information.

Preview: Downcasting

In our next lesson, we will delve into the concepts of downcasting and dynamic casting. Here's what we'll cover:

• Understanding Downcasting: We'll explain what downcasting is and why it's sometimes necessary, particularly in the context of polymorphism.
• Dynamic Casting: We'll explore dynamic casting, a safe way to perform downcasting, and understand how it differs from static casting.
• Risks and Considerations: We'll discuss the potential risks and limitations associated with downcasting, emphasizing the importance of using it judiciously.
• Practical Scenarios: By examining real-world scenarios, we'll demonstrate where and why downcasting is used in programming.
• Syntax and Usage: We'll break down the syntax of dynamic_cast and show how to use it effectively in your code.