Override & Final Keywords — Use override and final keywords (intro)

Virtual functions have been a cornerstone of C++ polymorphism since the language's earliest days, yet for decades programmers had no compiler-checked way to declare that a member function was intended to override a base-class virtual. A simple typo in a function signature — a mismatched parameter type, a missing const qualifier, or an incorrect return type — would silently introduce a new function rather than overriding the base version. The resulting bugs were notoriously difficult to diagnose because the code would compile and link without error, yet dispatch would bypass the derived implementation entirely at run time.

Similarly, library designers lacked a portable mechanism to lock down a class or virtual function so that downstream code could not extend or replace it. Compilers offered vendor-specific attributes (e.g., MSVC's __sealed), but there was no standard, cross-platform solution. The C++11 standard addressed both problems simultaneously by introducing the contextual keywords override and final, giving programmers explicit, compiler-enforced control over virtual dispatch semantics.

The central question these keywords address is deceptively simple: How can we make the compiler verify that a derived-class function actually overrides a base-class virtual, and how can we prevent further overriding when the design demands it? The answer reshapes how modern C++ inheritance hierarchies are designed and maintained.

Before diving into syntax, it is essential to understand the design rationale behind these two keywords. Both are contextual keywords (sometimes called identifiers with special meaning): they carry keyword semantics only when they appear in specific syntactic positions — namely, after the parameter list of a member function declarator or after a class name. Outside those positions, override and final remain valid identifiers, preserving backward compatibility with pre-C++11 code that may have used them as variable or function names.

The diagram above illustrates the fundamental value proposition of override. On the left, the derived class declares void draw(float x) when the base class expects void draw(int x). Because C++ treats these as distinct overloaded functions rather than an override, the derived version is never invoked through a base-class pointer — a scenario sometimes called accidental hiding. On the right, the addition of the override specifier turns this latent defect into an immediate diagnostic, shifting error detection from the testing phase to the compilation phase.

Compiler Verification Rules for override

When the compiler encounters a member function declaration annotated with override, it performs a multi-step verification. First, it searches the direct and indirect base classes for a virtual function with the same name. Then it checks that the candidate base function's signature — including parameter types, const/volatile qualifiers, ref-qualifiers, and return type (with covariant return relaxation) — matches exactly. If no matching base virtual is found, the compiler emits a diagnostic error. Crucially, override does not change the function's behavior at all; it is purely a compile-time assertion with zero run-time cost.

Signature-Matching Criteria

Compiler Enforcement of final

The final specifier operates at two distinct levels. When applied to a virtual function, it instructs the compiler to reject any attempt to override that function in a further-derived class. When applied to a class definition, it prohibits any class from inheriting from it at all. In addition to the semantic guarantee, final can enable compiler optimizations: if the compiler knows a virtual call target cannot be overridden, it may devirtualize the call — replacing an indirect vtable lookup with a direct function call, potentially enabling inlining.

Understanding where override and final can appear — and in what combinations — is essential for writing correct modern C++. The following diagram enumerates the six principal usage patterns, organized by whether the specifier applies to a function or a class.

Placement Rules

• Function specifiers appear after the parameter list and cv/ref qualifiers, but before the pure specifier (= 0) and function body: void f() const override = 0;
• When both are present on a function, either order is syntactically valid (override final or final override), but override final is the conventional ordering.
• Class-level final appears after the class name and before the base-class list: class Leaf final : public Base { };
• override cannot appear on non-virtual functions, constructors, static member functions, or destructors that do not override a base destructor.

Consider a classic polymorphic shape hierarchy where a base class Shape defines a virtual interface, and derived classes like Circle and FixedCircle override various functions. We will introduce several deliberate errors and show how override and final catch them at compile time.

The override and final keywords represent the introductory layer of compile-time polymorphism control in C++. As you progress through advanced topics, you will encounter several mechanisms that build on or interact with these concepts. Understanding these connections now will provide a roadmap for deeper study.

Looking ahead, the C++20 standard introduced Concepts and Modules, which continue the theme of shifting error detection to compile time. Concepts constrain template parameters in much the same spirit that override constrains virtual function declarations — both transform silent failures into explicit compile-time diagnostics. Meanwhile, coroutines and std::expected in C++23 continue this evolution toward safer, more expressive code. The discipline of annotating intent — which override and final exemplify — is a recurring theme in modern C++ design.