Какой смысл в конечной виртуальной функции?

Обычно final не будет использоваться в определении виртуальной функции базового класса. final будет использоваться производным классом, который переопределяет функцию, чтобы предотвратить дальнейшее переопределение функции другими производными типами. Поскольку переопределяющая функция обычно должна быть виртуальной, это означает, что любой может переопределить эту функцию в другом производном типе. final позволяет указать функцию, которая переопределяет другую, но не может быть переопределена сама.

Например, если вы разрабатываете иерархию классов и вам нужно переопределить функцию, но вы не хотите, чтобы пользователи иерархии классов делали то же самое, вы можете пометить функции как окончательные в своих производных классах.

Мне это вообще не кажется полезным. Я думаю, что это был просто пример для демонстрации синтаксиса.

Одно из возможных применений - если вы не хотите, чтобы f действительно можно было переопределить, но вы все еще хотите создать vtable, но это все еще ужасный способ делать что-то.

Чтобы функция была помечена final, она должна быть virtual, т. е. в С++ 11 10.3 абз. 2:

[...] Для удобства мы говорим, что любая виртуальная функция переопределяет себя.

и пункт 4:

Если виртуальная функция f в каком-то классе B помечена спецификатором virt final, а в классе D, производном от B, функция D::f переопределяет B::f, программа некорректна. [...]

т. е. final требуется использовать только с виртуальными функциями (или с классами для блокировки наследования). Таким образом, в примере необходимо использовать virtual, чтобы он был действительным кодом C++.

РЕДАКТИРОВАТЬ: Чтобы быть полностью ясным: «точка» спросила о проблемах, почему виртуальный вообще используется. Основная причина, по которой он используется, заключается в том, что (i) в противном случае код не скомпилировался бы, и (ii) зачем усложнять пример, используя больше классов, когда достаточно одного? Таким образом, в качестве примера используется ровно один класс с виртуальной конечной функцией.

Не понимаю смысла вводить виртуальную функцию и сразу помечать ее как final.

Цель этого примера — проиллюстрировать, как работает final, и он делает именно это.

Практическая цель может состоять в том, чтобы увидеть, как виртуальная таблица влияет на размер класса.

struct Base2 {
    virtual void f() final;
};
struct Base1 {
};

assert(sizeof(Base2) != sizeof(Base1)); //probably

Base2 можно просто использовать для проверки специфики платформы, и нет смысла переопределять f(), поскольку он существует только для целей тестирования, поэтому он помечен final. Конечно, если вы это делаете, значит что-то не так в дизайне. Лично я бы не стал создавать класс с функцией virtual только для того, чтобы проверить размер vfptr.

При рефакторинге унаследованного кода (например, при удалении виртуального метода из материнского класса) полезно убедиться, что ни один из дочерних классов не использует эту виртуальную функцию.

// Removing foo method is not impacting any child class => this compiles
struct NoImpact { virtual void foo() final {} };
struct OK : NoImpact {};

// Removing foo method is impacting a child class => NOK class does not compile
struct ImpactChildClass { virtual void foo() final {} };
struct NOK : ImpactChildClass { void foo() {} };

int main() {}

Добавление к хорошим ответам выше. Вот известное приложение final (очень вдохновленное Java). Предположим, мы определили функцию wait() в базовом классе и нам нужна только одна реализация wait() во всех его потомках. В этом случае мы можем объявить wait() как final.

Например:

class Base { 
   public: 
       virtual void wait() final { cout << "I m inside Base::wait()" << endl; }
       void wait_non_final() { cout << "I m inside Base::wait_non_final()" << endl; }
}; 

а вот определение производного класса:

class Derived : public Base {
      public: 
        // assume programmer had no idea there is a function Base::wait() 

        // error: wait is final
        void wait() { cout << "I am inside Derived::wait() \n"; } 
        // that's ok    
        void wait_non_final() { cout << "I am inside Derived::wait_non_final(); }

} 

Было бы бесполезно (и неправильно), если бы функция wait() была чисто виртуальной функцией. В этом случае: компилятор попросит вас определить wait() внутри производного класса. Если вы это сделаете, это выдаст вам ошибку, потому что wait() является окончательным.

Почему конечная функция должна быть виртуальной? (что также сбивает с толку) Потому что (imo) 1) концепция final очень близка к концепции виртуальных функций [виртуальные функции имеют много реализаций - у финальных функций есть только одна реализация], 2) легко реализовать окончательный эффект с помощью vtables.

Вот почему вы можете объявить функцию как virtual, так и final в базовом классе:

class A {
    void f();
};

class B : public A {
    void f(); // Compiles fine!
};

class C {
    virtual void f() final;
};

class D : public C {
    void f(); // Generates error.
};

Функция, помеченная final, должна также быть virtual. Пометка функции final не позволяет объявить функцию с тем же именем и сигнатурой в производном классе.

Вместо этого:

public:
    virtual void f();

Я считаю полезным написать это:

public:
    virtual void f() final
        {
        do_f(); // breakpoint here
        }
protected:
    virtual void do_f();

Основная причина в том, что теперь у вас есть единственное место для точки останова перед отправкой в ​​любую из потенциально многих переопределенных реализаций. К сожалению (ИМХО), говоря «окончательная», нужно также сказать «виртуальная».

Я нашел еще один случай, когда виртуальную функцию полезно объявить как final. Этот случай является частью списка предупреждений SonarQube. В описании предупреждения говорится:

Вызов переопределяемой функции-члена из конструктора или деструктора может привести к неожиданному поведению при создании экземпляра подкласса, который переопределяет функцию-член.

Например:
– По контракту конструктор класса подкласса начинается с вызова конструктора родительского класса.
– Конструктор родительского класса вызывает родительскую функцию-член, а не функцию, переопределенную в дочернем классе, что сбивает с толку дочернего разработчик класса.
— Это может привести к неопределенному поведению, если функция-член является чисто виртуальной в родительском классе.

Пример несовместимого кода

class Parent {
  public:
    Parent() {
      method1();
      method2(); // Noncompliant; confusing because Parent::method2() will always been called even if the method is overridden
    }
    virtual ~Parent() {
      method3(); // Noncompliant; undefined behavior (ex: throws a "pure virtual method called" exception)
    }
  protected:
    void         method1() { /*...*/ }
    virtual void method2() { /*...*/ }
    virtual void method3() = 0; // pure virtual
};

class Child : public Parent {
  public:
    Child() { // leads to a call to Parent::method2(), not Child::method2()
    }
    virtual ~Child() {
      method3(); // Noncompliant; Child::method3() will always be called even if a child class overrides method3
    }
  protected:
    void method2() override { /*...*/ }
    void method3() override { /*...*/ }
};

Совместимое решение

class Parent {
  public:
    Parent() {
      method1();
      Parent::method2(); // acceptable but poor design
    }
    virtual ~Parent() {
      // call to pure virtual function removed
    }
  protected:
    void         method1() { /*...*/ }
    virtual void method2() { /*...*/ }
    virtual void method3() = 0;
};

class Child : public Parent {
  public:
    Child() {
    }
    virtual ~Child() {
      method3(); // method3() is now final so this is okay
    }
  protected:
    void method2() override { /*...*/ }
    void method3() final    { /*...*/ } // this virtual function is "final"
};

virtual + final используются в одном объявлении функции, чтобы сделать пример коротким.

Что касается синтаксиса virtual и final, пример из Википедии будет более выразительным, если ввести struct Base2 : Base1 с Base1, содержащей virtual void f();, и Base2, содержащей void f() final; (см. ниже).

Стандарт

Ссылаясь на N3690:

• virtual, так как function-specifier может быть частью decl-specifier-seq
• final может быть частью virt-specifier-seq

Не существует правила, согласно которому необходимо использовать вместе ключевое слово virtual и идентификаторы со специальным значением final. Раздел 8.4, определения функций (обратите внимание, опция = необязательно):

определение функции:

атрибут-спецификатор-seq(opt) decl-specifier-seq(opt) декларатор virt-specifier-seq(opt) функция-тело

Упражняться

В C++11 вы можете опустить ключевое слово virtual при использовании final. Это компилируется в gcc > 4.7.1, в clang > 3.0 с C++ 11, в msvc, ... (см. обозреватель компилятора).

struct A
{
    virtual void f() {}
};

struct B : A
{
    void f() final {}
};

int main()
{
    auto b = B();
    b.f();
}

PS: пример на cppreference также не использует виртуальный вместе с final в такая же декларация.

PPS: То же самое относится и к override.