Mastering Virtual Functions

Mastering Virtual Functions is a milestone for every C++ developer. They are the engine behind Runtime Polymorphism, allowing your code to be extensible, maintainable, and "open for extension but closed for modification."

Let's explore what is the need for virtual functions, how they work under the hood, memory layout illustration and essential things to know before using them.

𝚃𝚑𝚎 "𝚆𝚑𝚢": 𝚆𝚑𝚊𝚝 𝚒𝚜 𝚝𝚑𝚎 𝚗𝚎𝚎𝚍 𝚏𝚘𝚛 𝚅𝚒𝚛𝚝𝚞𝚊𝚕 𝙵𝚞𝚗𝚌𝚝𝚒𝚘𝚗𝚜?

In C++, pointers are "static". If you have a Base class pointer pointing to a Derived object, calling a member function through that pointer will, by default, execute the Base version of that function. This happens because the compiler performs Early Binding (Static Binding), deciding which function to call based on the type of the pointer rather than the actual object.

In the above example when draw() function is called using base pointer(Shape*), the draw() function from base class is called rather than calling the draw() function from Circle, Line classes.

Problem: Imagine you are building a canvas that holds a list of different shapes: Circle, Line, and Rectangle. All of these inherit from a base class called Shape. if you store the objects of the derived classes in a list of Shape*, the compiler performs Early Binding and calls the Base version of that function for all the objects.

𝚃𝚑𝚎 𝚂𝚘𝚕𝚞𝚝𝚒𝚘𝚗: 𝙷𝚘𝚠 𝚅𝚒𝚛𝚝𝚞𝚊𝚕 𝙵𝚞𝚗𝚌𝚝𝚒𝚘𝚗𝚜 𝙵𝚒𝚡 𝚃𝚑𝚒𝚜

By marking a function as virtual in the base class, you tell the compiler: "Do not decide which function to call now. Wait until the program is running".

This enables Late Binding (Dynamic Binding). Even if you use a Base class pointer, C++ will look at the actual object type at runtime and calls the correct overridden implementation.

𝙷𝚘𝚠 𝙸𝚝 𝚆𝚘𝚛𝚔𝚜 𝚄𝚗𝚍𝚎𝚛 𝚃𝚑𝚎 𝙷𝚘𝚘𝚍, 𝙼𝚎𝚖𝚘𝚛𝚢 𝙸𝚕𝚕𝚞𝚜𝚝𝚛𝚊𝚝𝚒𝚘𝚗

To resolve the actual function’s address or definition at run time, C++ compiler adds some additional data structure around virtual functions i.e.

• 𝘃𝗧𝗮𝗯𝗹𝗲: It is a static array of function pointers that contains the addresses all virtual functions of this class. Compiler builds this vTable at compile time. Every class that has at least one virtual member function in it has a vTable associated with it.

• 𝘃𝗣𝗼𝗶𝗻𝘁𝗲𝗿: A hidden pointer added to every object instance of a class with virtual functions. It points to the class’s vTable. This vPointer will be used to find the actual function address from vTable at run time.

Now assume, a new class called SlantedLine is derived from Line class and implemented the draw() function.

The memory layout after adding a new class will be as follows (new member variables are shown to represent that the vPointer is stored at the start of the object's memory):

what exactly happens when a call to virtual function is executed:

• vPointer hidden in the first 4 bytes of the object will be fetched.

• vTable of this class is accessed through the fetched vPointer.

• From the vTable corresponding function’s address will be fetched.

• Function will be executed from that function pointer.

Note:

• vTable stores the memory addresses of the most-derived versions of the virtual functions.

• vPointer is initialized and whenever a constructor is called, and it is set to point to its corresponding class vTable.

𝙴𝚜𝚜𝚎𝚗𝚝𝚒𝚊𝚕 𝚝𝚑𝚒𝚗𝚐𝚜 𝚝𝚘 𝚛𝚎𝚖𝚎𝚖𝚋𝚎𝚛

𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗗𝗲𝘀𝘁𝗿𝘂𝗰𝘁𝗼𝗿𝘀:

If a Derived object is deleted through a Base class pointer, only the Base class Destructor runs. This can lead to memory leaks if the derived class has allocated any memory or resources and never cleaned up.

In order to avoid such memory leaks, making the base destructor as virtual ensures the Derived destructor is called first, followed by the Base destructor, cleaning the entire object correctly.

𝘃𝗧𝗮𝗯𝗹𝗲 𝗢𝗿𝗱𝗲𝗿 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝗰𝗲:

In typical C++ development, the compiler manages vTable order internally by following the declaration order in the Base class. Any new virtual functions added only in the Derived class are appended to the end of the vTable, ensuring all indices inherited from the Base remain valid.

However, reordering the virtual functions in a published base class can change vTable indices and break binary compatibility for clients compiled against an older version. Hence, it is recommended to preserve the base class virtual functions order and append new virtual functions at the end.

𝗗𝗶𝗮𝗺𝗼𝗻𝗱 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝘄𝗶𝘁𝗵 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗶𝗻𝗵𝗲𝗿𝗶𝘁𝗮𝗻𝗰𝗲:

Details on diamond problem are available here: Inheritance and Diamond Problem

𝗔𝗱𝗱𝗶𝘁𝗶𝗼𝗻𝗮𝗹 𝗡𝗼𝘁𝗲𝘀:

• Constructors cannot be virtual because an object's virtual mechanism is not fully set up until the constructor completes.

• Virtual functions introduce a slight performance cost due to the extra indirection (dereferencing the vPointer and vTable) and also extra overhead of one vPointer for each object.

• There is a concept of pure virtual function with no implementation in the base class, declared using the = 0 syntax (e.g., virtual void draw() = 0;). It forces derived classes to provide their own implementation. Any class containing at least one pure virtual function becomes an abstract class and cannot be instantiated