Use cases for final classes

Question

I was reading comments on Herb Sutter\'s Guru of the Week redux about virtual functions, and finally saw him mentioning this:

[...] “uses

Answer 1

final might be useful when you provide a (sort of) facade to the initial interface, which is easier to use by subclasses. Consider:

class IMovable {
  public:
    void GoTo(unsigned position) = 0;
}

class Stepper : public IMovable {
  public:
    void GoTo(unsigned position) final;
  protected:
    virtual void MoveLeft() = 0;
    virtual void MoveRight() = 0;
}

void Stepper::GoTo(unsigned position) {
  for(;current_pos < position; current_pos++) {
     MoveRight(); 
  }
  for(;current_pos > position; current_pos--) {
     MoveLeft();
  } 
}       

Now if you want to derive from Stepper you see that you should override MoveRight and MoveLeft, but you shouldn't override GoTo.

It is obvious on this small example, but if IMovable had 20 methods and Stepper had 25, and there were default implementations, than you might have hard time figuring out what you should and what you shouldn't override. I have met a situation like this in a hardware-related library. But I wouldn't call this a major problem worth adressing by the standard;)

Answer 2

One interesting unusual use case I have found I described here. In short, by preventing inheritance from your int-like class, you buy yourself a possibility to replace it with a built-in type in the future releases of your library, without the risk of breaking your user's code.

But a more common example is devirtualization. If you mark your class as final, compiler can apply certain run-time optimizations. For instance,

struct Object {
  virtual void run() = 0;
  virtual ~Object() {}
};

struct Impl final : Object
{
  void run() override {}
};

void fun(Impl & i)
{
  i.run(); // inlined!
}

The call to i.run() can be now inlined due to final specifier. The compiler knows that vtable look-up will not be needed.