[转][C++ 11]override and final - write clean and maintainable C++ code

原文:

http://arne-mertz.de/2015/12/modern-c-features-override-and-final/

 

Today I write about a pair of less often discussed, less complicated features introduced in C++11, which are nevertheless useful. Both can provide some additional security and clarity when it comes to deriving classes and overloading virtual functions. 

Overriding virtual methods

Have you ever come across the problem that you overloaded a virtual function in a derived class but it did not get called? Or worse – you had to change the signature of the base class virtual function. Searching for all the derived classes that overloaded the function can be tricky, and Murphy’s law states that you forget at least one of them.

 

 1 struct Base {
 2   virtual void doSomething(int i) const {
 3     std::cout << "Base::doSomething with " << i << '\n';
 4   }
 5 };
 6 
 7 struct Derived : Base {
 8   virtual void doSomething(int i) {
 9     std::cout << "Derived::doSomething with " << i << '\n';
10   }
11 };
12 
13 void callIt(Base& b) {
14   b.doSomething(42);
15 }
16 
17 int main() {
18   Derived d;
19   callIt(d); //OOPS: "Base::doSomething with 42"
20 }

Trust me, I have spent hours looking for errors like this. If you have not spotted it yet: Derived::doSomething is missing the const specifier. Therefore it does not have the same signature and is not overloading Base::doSomething, period. There are compilers out there emitting warnings for that kind of stuff, but those warnings appear also if we did in fact not want to overload the virtual function.

 

For cases like this, we’d like to have the tools to distinguish between accidents where the compiler preferably should emit an error and intent, where it should remain silent. Therefore, C++11 introduced the keyword override:

1 struct Derived : public Base {
2   void doSomething(int i) override { //ERROR: does not override Base::doSomething
3     std::cout << "Derived::doSomething with " << i << '\n';
4   }
5 };

It’s as easy as this. Add the keyword, and the compiler checks if this method in fact is overriding a base class method. Thus the aforementioned change of the function signature in the base class will lead to compiler errors in every derived class’ method that declares to be overriding but isn’t until their signature is changed, too.

Override brings an additional benefit if you apply it consistently: Previous to C++11 it was a debatable question of style if overriding functions in derived classes should be marked virtual as well or not. Since functions that override virtual functions are automatically virtual as well, it was not necessary, but explicitly stating that the function should be virtual documented that fact. With override, the documentation is already in place and virtual is only needed for the topmost virtual functions.

 

Preventing virtual function overrides

The almost exact opposite case is when you define virtual functions in base classes but don’t want deriving classes to override them. This can be the case when you design the top layers of class hierarchies that are designed to be extended by deriving classes. A crucial point is that virtual functions can be overridden even if the base class function is private:

 1 //---- mylib.h ----------------------
 2 class AbstractLibraryBase {
 3 public:
 4   void templateMethod() const {
 5     std::cout << "Something about " << implDetail() << '\n';
 6   }
 7 private:
 8   virtual int implDetail() const = 0;
 9 };
10 
11 class LibraryClass : public AbstractLibraryBase {
12 private:
13   int implDetail() const override {
14     return 42;
15   }
16 };

 1 #include 
 2 class EvilHijacker : public LibraryClass {
 3   int implDetail() const override {
 4     return 73; //overriding the private method
 5   }
 6 };
 7 
 8 int main() {
 9   EvilHijacker eh;
10   eh.templateMethod(); //Something about 73
11 }

Until C++11 there was little you could do to prevent such things. Workarounds had to be used to further separate those private virtual methods from derived classes and prevent the hijack. Now we have the keyword final to the rescue:

1 class LibraryClass : public AbstractLibraryBase {
2 private:
3   int implDetail() const final override {
4     return 42;
5   }
6 };

1 class EvilHijacker : public LibraryClass {
2   int implDetail() const override; //ERROR: overriding final function...
3 };

Now it is impossible to further override implDetail in classes that derive from LibraryClass. It is, of course, possible to derive more classes from AbstractLibraryBase that can (and in this case have to) override the function.

A quick note on the positioning of both final and override:  both have to be positioned after const, volatile and reference specifiers, but before the pure specifier, i.e. the =0, if the function should have one. A pure and final function does not make sense since it makes the class abstract and no derived class can fix it, but there can be use cases for pure virtual overrides. It makes no difference if you write override final or final override. However, I prefer the latter as it reads more fluently.

Final classes

There is a second use for final: applied to a class definition directly after the class name, it prohibits any other class to derive from the class in question, no matter if it wants to inherit publicly or privately:

1 class NoDerivates final  /* : BaseClasses if needed */ {
2   // ...
3 };
4 
5 class Fail : public NoDerivates { //ERROR: canot derive from final base
6 };

Before using final for classes or methods consider if you really need to be

Updating your codebase

If you have an existing codebase it can be tedious to try to update all virtual functions with final and override. The decision to mark a function final needs to be decided from case to case, whereas adding the override specifier is straight forward. Whether you want to tackle the task and add the specifiers all at once or just fix those places you have to deal with anyways, here is a simple recipe:

Add the override specifier to every function of a class, virtual or not and recompile the class. The compiler will immediately complain about functions that are not overriding a virtual base class method. Remove the overrides that cause compiler errors and then remove the virtual specifier of any function that has an override specifier.

When you find a function that is declared virtual, you won’t always know immediately if it is the topmost virtual function or not, and finding all the overriding functions manually is hard. Luckily you can get help from your compiler. Temporarily mark the function in question final and recompile the project. The compiler will give you a list of all overriding functions in form of “cannot override final” errors.

Conclusion

Both override and final can help to avoid errors related to virtual functions. While final needs a bit of thought about when it should be applied and when not, the use of override is straight forward and there is no excuse to leave it away.