Embracing Modern C++ Safely - Excerpt
Learn how to utilize these C++ features and avoid pitfalls:
- override
- depracted atrribute
- extern template
- inline namespace
override
The override Member-Function Specifier
Decorating a function in a derived class with the contextual keyword override ensures that a virtual function having a compatible declaration exists in one or more of its base classes.
Description
The contextual keyword override can be provided at the end of a member-function declaration to ensure that the decorated function is indeed overriding a corresponding virtual member function in a base class, as opposed to hiding it or otherwise inadvertently introducing a distinct function declaration:
struct Base { virtual void f(int); void g(int); virtual void h(int) const; virtual void i(int) = 0; }; struct DerivedWithoutOverride : Base { void f(); // hides Base::f(int) (likely mistake) void f(int); // OK, implicitly overrides Base::f(int) void g(); // hides Base::g(int) (likely mistake) void g(int); // hides Base::g(int) (likely mistake) void h(int); // hides Base::h(int) const (likely mistake) void h(int) const; // OK, implicitly overrides Base::h(int) const void i(int); // OK, implicitly overrides Base::i(int) }; struct DerivedWithOverride : Base { void f() override; // Error, Base::f() not found void f(int) override; // OK, explicitly overrides Base::f(int) void g() override; // Error, Base::g() not found void g(int) override; // Error, Base::g() is not virtual. void h(int) override; // Error, Base::h(int) not found void h(int) const override; // OK, explicitly overrides Base::h(int) void i(int) override; // OK, explicitly overrides Base::i(int) };
Using this feature expresses design intent so that (1) human readers are aware of it and (2) compilers can validate it.
As noted, override is a contextual keyword. C++11 introduces keywords that have special meaning only in certain contexts. In this case, override is a keyword in the context of a declaration, but not otherwise using it as the identifier for a variable name, for example, is perfectly fine:
int override = 1; // OK
Use Cases
Ensuring that a member function of a base class is being overridden
Consider the following polymorphic hierarchy of error-category classes, as we might have defined them using C++03:
struct ErrorCategory { virtual bool equivalent(const ErrorCode& code, int condition); virtual bool equivalent(int code, const ErrorCondition& condition); }; struct AutomotiveErrorCategory : ErrorCategory { virtual bool equivalent(const ErrorCode& code, int condition); virtual bool equivolent(int code, const ErrorCondition& condition); };
Notice that there is a defect in the last line of the example above: equivalent has been misspelled. Moreover, the compiler did not catch that error. Clients calling equivalent on AutomotiveErrorCategory will incorrectly invoke the base-class function. If the function in the base class happens to be defined, the code might compile and behave unexpectedly at run time. Now, suppose that over time the interface is changed by marking the equivalence-checking function const to bring the interface closer to that of std::error_category:
struct ErrorCategory { virtual bool equivalent(const ErrorCode& code, int condition) const; virtual bool equivalent(int code, const ErrorCondition& condition) const; };
Without applying the corresponding modification to all classes deriving from ErrorCategory, the semantics of the program change due to the derived classes now hiding the base class’s virtual member function instead of overriding it. Both errors discussed above would be detected automatically if the virtual functions in all derived classes were decorated with override:
struct AutomotiveErrorCategory : ErrorCategory { bool equivalent(const ErrorCode& code, int condition) override; // Error, failed when base class changed bool equivolent(int code, const ErrorCondition& code) override; // Error, failed when first written };
What’s more, override serves as a clear indication of the derived-class author’s intent to customize the behavior of ErrorCategory. For any given member function, using override necessarily renders any use of virtual for that function syntactically and semantically redundant. The only cosmetic reason for retaining virtual in the presence of override would be that virtual appears to the left of the function declaration, as it always has, instead of all the way to the right, as override does now.
Potential Pitfalls
Lack of consistency across a codebase
Relying on override as a means of ensuring that changes to base-class interfaces are propagated across a codebase can prove unreliable if this feature is used inconsistently, i.e., not applied in every circumstance where its use would be appropriate. In particular, altering the signature of a virtual member function in a base class and then compiling the entire code base will always flag as an error any nonmatching derived-class function where override was used but might fail even to warn where it is not.
Further Reading
Various relationships among virtual, override, and final (see Section 3.1.“final” on page 1007) are presented in boccara20.
Scott Meyers advocates the use of the override specifier in meyers15b, “Item 12: Declare overriding functions override,” pp. 79–85.