Abstract Base Classes and Interfaces

1. Enforcing a Contract: Pure Virtual Functions

So far, when a derived class has overridden a virtual function, it has been optional. A Dog class could choose to override Animal::makeSound(), but it wasn't required to. What if we want to create a base class that serves as a blueprint, forcing all derived classes to implement a specific set of functions?

This is where pure virtual functions come in. A pure virtual function is a virtual function that the base class declares but does not define. This has two immediate and important consequences:

1. The class containing the pure virtual function becomes an abstract class.
2. Any concrete (non-abstract) class that inherits from it must provide an implementation for that function.

Let's see how this works in practice.

As you just saw, the = 0 syntax is a declaration that effectively says, "I am not providing an implementation for this function; it is up to my children to do so." This makes the class an incomplete blueprint, or "abstract," which is why the compiler prevents you from creating an object from it.

2. Using Abstract Classes to Create Interfaces

The most powerful application of abstract classes is to define interfaces. An interface is a class that consists of nothing but pure virtual functions (and a virtual destructor, which we know is crucial!). It defines a set of behaviors—a contract—without committing to any specific implementation. Any class that inherits from this interface and implements its functions can be treated polymorphically through a pointer or reference to the interface.

This is a fundamental technique for decoupling code. You can write functions that operate on an interface type, without needing to know anything about the concrete classes that implement it.

Let's continue with The Cherno's video to see a practical example of creating a Printable interface.

3. The Internals: What's in the V-Table?

Now for the crucial question: if a pure virtual function has no implementation in the base class, what does its vtable entry point to? It can't be null, as that would lead to a crash if it were ever called. And it can't point to a real function body, because one doesn't exist.

The compiler and C++ runtime have a specific mechanism for this. The vtable slot for a pure virtual function in an abstract class points to a special, globally available handler function. In the Itanium C++ ABI (used by GCC/Clang on Linux), this function is named __cxa_pure_virtual.

If you manage to call a pure virtual function—which should not happen in a well-formed program but can occur if you call it from the constructor or destructor of the abstract base class—the vtable dispatch will lead to __cxa_pure_virtual. This function's job is to terminate the program with an error message, alerting you to the mistake. It's a runtime safety net.

Let's see this in the context of reverse engineering.

The osdev.org wiki, a fantastic resource for low-level systems development, even shows what a minimal implementation of this handler looks like. This is exactly the kind of function you'd have to provide yourself if you were writing a C++ kernel from scratch without the standard library.

So, to summarize the internal mechanism:

1. You declare a function virtual ... = 0;.
2. The compiler marks the class as abstract.
3. In the vtable for this abstract class, the entry for the pure virtual function is filled with the address of __cxa_pure_virtual.
4. When a concrete class derives and implements the function, its vtable entry is updated to point to the new implementation, as with any regular virtual function.

class IShape {
public:
    virtual double getArea() const = 0;
    virtual void draw() const = 0;
    virtual ~IShape() = default;
};

class Circle : public IShape {
public:
    double getArea() const override { /* ... */ }
    // Note: draw() is NOT implemented
};

Conclusion

This lesson marks the end of our module on runtime polymorphism internals. You've now seen the full picture, from basic virtual functions to the complex machinery of virtual inheritance, and finally to how these concepts are used to create abstract classes and interfaces.

Key Takeaways:

• A pure virtual function is declared with = 0 and makes its class abstract.
• An abstract class cannot be instantiated directly.
• Derived classes must override all inherited pure virtual functions to become concrete (instantiable).
• A class with only pure virtual functions and a virtual destructor serves as a pure interface, defining a contract for other classes to implement.
• Internally, the vtable slot for a pure virtual function points to a runtime handler (like __cxa_pure_virtual) that terminates the program if called, providing a safety net against incorrect usage.

In our next module, we will shift gears to another concept that is absolutely fundamental to modern C++: Resource Management and the RAII Idiom. We'll explore how C++ provides powerful tools to automate memory and resource cleanup, moving beyond the manual new and delete calls we've used in our examples and into a safer, more robust style of programming.