Use C++11 Inheritance Control Keywords to Prevent Inconsistencies in Class Hierarchies

C  11 finger paint

For more than 30 years, C++ got along without inheritance control keywords. It wasn’t easy, to say the least. Disabling further derivation of a class was possible but tricky. To prevent users from overriding a virtual function in a derived class you had to lean over backwards. But not any more: Two new context-sensitive keywords make your job a lot easier. Here’s how they work.

C++11 adds two inheritance control keywords: override and final. override ensures that an overriding virtual function declared in a derived class has the same signature as that of the base class. final blocks further derivation of a class and further overriding of a virtual function. Let’s see how these watchdogs can eliminate design and implementation bugs in your class hierarchies.

Virtual Functions and override

A derived class can override a member function that was declared virtual in a base class. This is a fundamental aspect of object-oriented design. However, things can go wrong even with such a trivial operation as overriding a function. Two common bugs related to overriding virtual functions are:

  • Inadvertent overriding.
  • Signature mismatch.

First, let’s analyze the inadvertent overriding syndrome. You might inadvertently override a virtual function simply by declaring a member function that accidentally has the same name and signature as a base class’s virtual member function. Compilers and human readers rarely detect this bug because they usually assume that the new function is meant to override the base class’s function:

struct A
virtual void func();
};             
struct B: A{};
struct F{};
struct D: A, F
{
  void func();//meant to declare a new function but 
 //accidentally overrides A::func};

Reading the code listing above, you can’t tell for sure whether the member function D::func() overrides A::func() deliberately. It could be an accidental overriding that occurred because the parameter lists and the names of both functions are identical by chance.

A signature mismatch is a more commonplace scenario. It leads to the accidental creation of a new virtual function (instead of overriding an existing virtual function), as demonstrated in the following example:

struct G
{
 virtual void func(int);
};
struct H: G
{
 virtual void func(double); //accidentally creates a new virtual function
};

In this case, the programmer intended to override G::func() in class H. However, because H::func() has a different signature, the result is a new virtual function, not an override of a base class function. Not all compilers issue a warning in such cases, and those that do are sometimes configured to suppress this warning.

In C++11, you can eliminate these two bugs by using the new keyword override. override explicitly states that a function is meant to override a base class’s virtual function. More importantly, it checks for signature mismatches between the base class virtual function and the overriding function in the derived classes. If the signatures don’t match, the compiler issues an error message.

Let’s see how override can eliminate the signature mismatch bug:

struct G
{
 virtual void func(int);
};
struct H: G
{
 virtual void func(double) override; //compilation error
};

When the compiler processes the declaration of H::func() it looks for a matching virtual function in a base class. Recall that “matching” in this context means:

  • Identical function names.
  • A virtual specifier in the first base class that declares the function.
  • Identical parameter lists, return types (with one exception), cv qualifications etc., in both the base class’s function and the derived class’s overriding function.

If any of these three conditions isn’t met, you get a compilation error. In our example, the parameter lists of the two functions don’t match: G::func() takes int whereas H::func() takes double. Without the override keyword, the compiler would simply assume that the programmer meant to create a new virtual function in H.

Preventing the inadvertent overriding bug is trickier. In this case, it’s the lack of the keyword override that should raise your suspicion. If the derived class function is truly meant to override a base class function, it should include an explicit override specifier. Otherwise, assume that either D::func() is a new virtual function (a comment would be most appreciated in this case!), or that this may well be a bug.

final Functions and Classes

The C++11 keyword final has two purposes. It prevents inheriting from classes, and it disables the overriding of a virtual function. Let’s look at final classes first.

Certain classes that implement system services, infrastructure utilities, encryption etc., are often meant to be non-subclassable: The implementers don’t want clients to modify those classes by means of deriving new classes from them. Standard Library containers such as std::vector and std::list are another good example of non-subclassable types. These container classes don’t have a virtual destructor or indeed, any virtual member functions.

And yet, every now and then, programmers insist on deriving from std::vector without realizing the risks involved. In C++11, non-subclassable types should be declared final like this:

class TaskManager final{/*..*/};  
class PrioritizedTaskManager: public TaskManager {
};  //compilation error: base class TaskManager is final

In a similar vein, you can disable further overriding of a virtual function by declaring it final. If a derived class attempts to override a final function, the compiler issues an error message:

struct A
{
  virtual void func() const;
};
struct B: A
{
  void func() const override final; //OK
};
struct C: B
{
 void func()const; //error, B::func is final
};

It doesn’t matter whether C::func() is declared override. Once a virtual function is declared final, derived classes cannot override it.

Syntax and Terminology

I have thus far avoided two side issues pertaining to override and final. The first one is their unique location. Unlike virtual, inline, explicit extern, and similar function specifiers, these two keywords appear after the closing parenthesis of a function’s parameter list, or (in the case of non-subclassable classes) after the class name in a class declaration.

The peculiar location of these keywords is a consequence of another unusual property: override and final aren’t ordinary keywords. In fact officially, they aren’t keywords at all. C++11 considers them as identifiers that gain special meaning only when used in the specific contexts and locations as I have shown. In any other location or context, they are treated as identifiers. Consequently, the following listing makes perfectly valid C++11 code:

//valid C++11 code
int final=0;
bool override=false;
if (override==true){
 cout<<”override is: “<<override<<endl;}
struct D{} final;
struct A
{virtual bool func(); };
struct B:A
{ bool func() override final; };

It may seem surprising that final and override behave exactly like PL/1’s context sensitive keywords (CSK). Since 1972, C and later C++ always avoided CSK, adhering instead to the reserved keywords approach.

So why did the committee make final and override an exception? The CSK choice was a compromise. Adding override and final as reserved keywords might have caused existing C++ code to break. If the committee had introduced new reserved keywords, they probably would have chosen funky strings such as final_decl or _Override, tokens that were less likely to clash with user-declared identifiers in legacy C++ code. However, no one likes such ugly keywords (ask C users what they think of C99’s _Bool for example). That is why the CSK approach won eventually.

override and final become keywords in C++11, but only when used in specific contexts. Otherwise, they are treated as plain identifiers. The committee was reluctant to call override and final “context sensitive keywords” (which is what they truly are) though. Instead, they are formally referred to as “identifiers with special meaning.” Special indeed!

In Conclusion

The two new context-sensitive keywords override and final give you tighter control over hierarchies of classes, ridding you of some irritating inheritance-related bugs and design gaffes. override guarantees that an overriding virtual function matches its base class counterpart. final blocks further derivation of a class or further overriding of a virtual function. With respect to compiler support, GCC 4.7, Intel’s C++ 12, MSVC 11, and Clang 2.9 support these new keywords.

 

About the author

Danny Kalev is a certified system analyst and software engineer specializing in C++. Kalev has written several C++ textbooks and contributes C++ content regularly on various software developers’ sites. He was a member of the C++ standards committee and has a master’s degree in general linguistics.

See also:






 






  • yannick

    Thanks a lot for your enlightening posts. 
     
    Just a comment on the ‘final’ part shouldn’t C derive from B to have the compilation error ?

  • http://stefan-weigand.de Stefan

    Danny, thanks for this article. 
    But I think you have a bug in the ‘final’ example. 
    It should be 
    struct C : B instead of struct C : A

  • Danny Kalev

    Thank you both, Stefan and Yannick. You’re right of course. The base class should be B. A quick fix is on its way. 

  • BadDesign

    I’ve spotted 2 mistakes while going through this blog post: 
     
    1) In this code: 
    “H *p=new H; 
    p->func(5); //calls G::f 
    p->func(5.0); // calls H::f” 
     
    In both cases the function that is called is H::func because you don’t create an object of type G and assign the pointer to its base class, H (i.e. G* p = new H(); in which case it will call G::func() in both cases, because the functions have different signatures and when you call p->func(5.0) it will implicitly cast 5.0 to int and call the function from G) 
     
    2) In this code: “class TaskManager {/*..*/} final;” 
    The location of the final identifier is wrong, you are creating an object named final of type TaskManager, instead it should be “class TaskManager final {/*..*/};” 
     
    and because of what I said above this part is also incorrect: “or (in the case of non-subclassable classes) after the closing brace of a class declaration.”

  • Danny Kalev

    Thanks BadDesign for the valuable input. I’ve made some changes to the code listings and the text according to your comments. They should be correct now.