Какие выгоды дает компилятору новое ключевое слово final в C++?

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

С диспетчеризацией вызовов virtual для производного типа final вы можете быть уверены, что от этого типа больше ничего не происходит. Это означает, что (по крайней мере, теоретически) ключевое слово final позволило бы правильно разрешить некоторые вызовы virtual во время компиляции, что сделало бы возможным ряд оптимизаций, которые иначе были бы невозможны для вызовов virtual.

Например, если у вас есть delete most_derived_ptr, где most_derived_ptr — указатель на производный тип final, компилятор может упростить вызовы деструктора virtual.

Аналогично для вызовов virtual функций-членов для ссылок/указателей на наиболее производный тип.

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

Также может быть некоторая польза в том, чтобы сделать вывод, что (в отсутствие friends) вещи, отмеченные protected в final class, также эффективно становятся private.

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

1. Нахождение указателя v-таблицы и через него доступ к v-таблице
2. Нахождение указателя функции в v-таблице и выполнение вызова через него

По сравнению с прямым вызовом, когда адрес функции известен заранее (и жестко закодирован с помощью символа), это приводит к небольшим накладным расходам. Хорошим компиляторам удается сделать его всего на 10-15% медленнее, чем обычный вызов, что обычно несущественно, если у функции есть мясо.

Оптимизатор компилятора по-прежнему стремится избежать всевозможных накладных расходов, а девиртуализация вызовов функций, как правило, является легкой задачей. Например, см. в C++03:

struct Base { virtual ~Base(); };

struct Derived: Base { virtual ~Derived(); };

void foo() {
  Derived d; (void)d;
}

Кланг получает:

define void @foo()() {
  ; Allocate and initialize `d`
  %d = alloca i8**, align 8
  %tmpcast = bitcast i8*** %d to %struct.Derived*
  store i8** getelementptr inbounds ([4 x i8*]* @vtable for Derived, i64 0, i64 2), i8*** %d, align 8

  ; Call `d`'s destructor
  call void @Derived::~Derived()(%struct.Derived* %tmpcast)

  ret void
}

Как видите, компилятор уже был достаточно умен, чтобы определить, что d является Derived, и нет необходимости нести накладные расходы на виртуальный вызов.

На самом деле, это так же хорошо оптимизировало бы следующую функцию:

void bar() {
  Base* b = new Derived();
  delete b;
}

Однако бывают ситуации, когда компилятор не может прийти к такому выводу:

Derived* newDerived();

void deleteDerived(Derived* d) { delete d; }

Здесь мы могли ожидать (наивно), что вызов deleteDerived(newDerived()); приведет к тому же коду, что и раньше. Однако это не так:

define void @foobar()() {
  %1 = tail call %struct.Derived* @newDerived()()
  %2 = icmp eq %struct.Derived* %1, null
  br i1 %2, label %_Z13deleteDerivedP7Derived.exit, label %3

; <label>:3                                       ; preds = %0
  %4 = bitcast %struct.Derived* %1 to void (%struct.Derived*)***
  %5 = load void (%struct.Derived*)*** %4, align 8
  %6 = getelementptr inbounds void (%struct.Derived*)** %5, i64 1
  %7 = load void (%struct.Derived*)** %6, align 8
  tail call void %7(%struct.Derived* %1)
  br label %_Z13deleteDerivedP7Derived.exit

_Z13deleteDerivedP7Derived.exit:                  ; preds = %3, %0
  ret void
}

Соглашение может предписывать, что newDerived возвращает Derived, но компилятор не может сделать такое предположение: а что, если он вернет что-то более производное? Таким образом, вы можете увидеть весь уродливый механизм, связанный с извлечением указателя v-таблицы, выбором соответствующей записи в таблице и, наконец, выполнением вызова.

Однако если мы поместим final, то мы дадим компилятору гарантию, что это не может быть что-то другое:

define void @deleteDerived2(Derived2*)(%struct.Derived2* %d) {
  %1 = icmp eq %struct.Derived2* %d, null
  br i1 %1, label %4, label %2

; <label>:2                                       ; preds = %0
  %3 = bitcast i8* %1 to %struct.Derived2*
  tail call void @Derived2::~Derived2()(%struct.Derived2* %3)
  br label %4

; <label>:4                                      ; preds = %2, %0
  ret void
}

Вкратце: final позволяет компилятору избежать накладных расходов на виртуальные вызовы соответствующих функций в ситуациях, когда их обнаружение невозможно.

В зависимости от того, как вы на это смотрите, у компилятора есть еще одно преимущество (хотя это преимущество просто повторяется для пользователя, так что, возможно, это не преимущество компилятора): компилятор может избежать выдачи предупреждений для конструкций с неопределенным поведением, которые нужно быть переопределяемым.

Например, рассмотрим этот код:

class Base
{
  public:
    virtual void foo() { }
    Base() { }
    ~Base();
};

void destroy(Base* b)
{
  delete b;
}

Многие компиляторы будут выдавать предупреждение для невиртуального деструктора b при обнаружении delete b. Если бы класс Derived наследовался от Base и имел свой собственный деструктор ~Derived, использование destroy в динамически выделяемом экземпляре Derived обычно (в соответствии со спецификацией поведение не определено) вызывало бы ~Base, но не вызывало бы ~Derived. Таким образом, операции очистки ~Derived не будут выполняться, и это может быть плохо (хотя в большинстве случаев, вероятно, не катастрофично).

Однако если компилятор знает, что Base не может быть унаследовано, то нет проблем в том, что ~Base не является виртуальным, потому что никакая производная очистка не может быть случайно пропущена. Добавление final к class Base дает компилятору информацию, чтобы не выдавать предупреждение.

Я точно знаю, что использование final таким образом подавит предупреждение с помощью Clang. Я не знаю, выдают ли здесь другие компиляторы предупреждение или учитывают ли они окончательность при определении того, следует ли выдавать предупреждение.