Специфікатори override, final та віртуальні деструктори

Коли компілятор не бачить помилки: підступність сигнатур

Припустимо, ви розробляєте графічну систему з класом Widget та його нащадками. Базовий клас оголошує віртуальний метод render() для відображення віджета на екрані:

#include <iostream>

class Widget
{
public:
    virtual void render() const
    {
        std::cout << "Widget: базове відображення\n";
    }
};

class Button : public Widget
{
public:
    // Програміст забув const — це НЕ перевизначення!
    void render()
    {
        std::cout << "Button: малюю кнопку\n";
    }
};

int main()
{
    Button btn;
    Widget* ptr = &btn;
    
    ptr->render();  // Очікуємо: "Button: малюю кнопку"
    
    return 0;
}

Інтуїтивно ми очікуємо, що виклик ptr->render() виведе "Button: малюю кнопку", адже ptr адресує об'єкт Button, а метод Widget::render() є віртуальним. Проте результат шокує:

Поліморфізм не спрацював! Метод Button::render() не є перевизначенням Widget::render(), адже сигнатури різні: Widget::render() є константним методом (має const після параметрів), а Button::render() — ні. Компілятор вважає їх різними методами і мовчки компілює код без жодних попереджень.

Це одна з найпідступніших проблем віртуальних функцій у C++: випадкове перевантаження замість перевизначення. Програміст мав намір перевизначити метод, але через дрібну помилку в сигнатурі (забутий const, інший тип параметра, додатковий &) створив незалежний метод. Код компілюється, виглядає правильним, але поводиться неочікувано.

У цій статті ми вивчимо інструменти C++11, які вирішують цю проблему (специфікатори override і final), а також розглянемо критично важливу тему віртуальних деструкторів — механізм, без якого робота з поліморфними об'єктами призводить до витоків пам'яті та Undefined Behavior.

Специфікатор override: компілятор як перший рецензент коду

Проблема: мовчазне перевантаження замість перевизначення

Як ми побачили у вступному прикладі, забута модифікація в сигнатурі методу призводить до того, що метод похідного класу не є перевизначенням, хоча програміст мав саме такий намір. Компілятор C++ не видає помилку, адже технічно можливо мати два методи з однаковим ім'ям, але різними сигнатурами — це перевантаження.

Розглянемо кілька типових сценаріїв такої помилки:

class Base
{
public:
    virtual void process(int x) const { /* ... */ }
    virtual int getValue() { return 0; }
    virtual void update() { /* ... */ }
};

class Derived : public Base
{
public:
    // ❌ Помилка 1: забули const
    void process(int x) { /* ... */ }
    
    // ❌ Помилка 2: інший тип параметра (double замість int)
    void process(double x) const { /* ... */ }
    
    // ❌ Помилка 3: інший тип повернення
    double getValue() { return 0.0; }
    
    // ❌ Помилка 4: додали параметр за замовчуванням (змінилася сигнатура)
    void update(bool force = false) { /* ... */ }
};

Жоден із методів Derived не є перевизначенням відповідних методів Base, адже сигнатури різні. Проте компілятор мовчить — код компілюється без попереджень. Поліморфізм не працює, а програміст може витратити години на налагодження, намагаючись зрозуміти, чому викликається базовий метод замість похідного.

Рішення: специфікатор override

C++11 додав специфікатор override — спеціальну мітку, яку можна додати після сигнатури методу, щоб явно вказати компілятору: «цей метод має бути перевизначенням віртуального методу базового класу». Якщо компілятор не знайде відповідного віртуального методу в базовому класі (або сигнатури не збігаються), він видасть помилку компіляції:

class Base
{
public:
    virtual void process(int x) const { /* ... */ }
};

class Derived : public Base
{
public:
    // ✅ Компілятор перевірить, чи це дійсно перевизначення
    void process(int x) const override { /* ... */ }
};

Тепер компілятор гарантує, що Derived::process() дійсно є перевизначенням Base::process(). Якщо ми помилимося в сигнатурі, компілятор негайно повідомить:

class Base
{
public:
    virtual void process(int x) const { /* ... */ }
};

class Derived : public Base
{
public:
    // ❌ Помилка компіляції: метод не перевизначує жоден базовий метод
    void process(int x) override { /* ... */ }  // Забули const!
};

Компілятор видасть помилку на кшталт:

error: 'void Derived::process(int)' marked 'override', but does not override

Це змушує програміста виправити сигнатуру (додати const) або усвідомити, що метод не призначений для перевизначення.

Синтаксис та розміщення

Специфікатор override розміщується після списку параметрів та специфікатора const (якщо метод константний), але перед тілом методу:

class Base
{
public:
    virtual void foo() const;
    virtual int bar(double x);
};

class Derived : public Base
{
public:
    void foo() const override;        // ✅ Правильне розміщення
    int bar(double x) override;       // ✅ Правильне розміщення
};

Ключове слово virtual у похідному класі необов'язкове, якщо використовується override — сам факт перевизначення робить метод віртуальним. Проте багато програмістів залишають virtual для ясності:

class Derived : public Base
{
public:
    virtual void process(int x) const override;
};

class Derived : public Base
{
public:
    void process(int x) const override;
};

Обидва варіанти коректні та еквівалентні. override сам по собі гарантує віртуальність. Вибір — питання стилю команди.

Практичний приклад: ієрархія фігур

Розглянемо повний приклад з використанням override:

#include <iostream>
#include <cmath>

class Shape
{
public:
    virtual ~Shape() = default;
    
    virtual double getArea() const = 0;  // Чисто віртуальна функція
    virtual void describe() const
    {
        std::cout << "Це базова фігура\n";
    }
};

class Circle : public Shape
{
private:
    double radius;

public:
    Circle(double r) : radius(r) {}
    
    double getArea() const override
    {
        return 3.14159 * radius * radius;
    }
    
    void describe() const override
    {
        std::cout << "Це коло з радіусом " << radius << "\n";
    }
};

class Rectangle : public Shape
{
private:
    double width, height;

public:
    Rectangle(double w, double h) : width(w), height(h) {}
    
    double getArea() const override
    {
        return width * height;
    }
    
    void describe() const override
    {
        std::cout << "Це прямокутник " << width << "x" << height << "\n";
    }
};

int main()
{
    Circle circle(5.0);
    Rectangle rect(4.0, 6.0);
    
    Shape* shapes[] = { &circle, &rect };
    
    for (Shape* shape : shapes) {
        shape->describe();
        std::cout << "  Площа: " << shape->getArea() << "\n\n";
    }
    
    return 0;
}

У цьому прикладі всі перевизначення позначені override. Якщо програміст випадково помилиться в сигнатурі (наприклад, забуде const), компілятор негайно повідомить про помилку.

Специфікатор final: заборона подальших змін

Мотивація: коли перевизначення небажане

Іноді потрібно заборонити подальше перевизначення віртуального методу або наслідування класу. Причини можуть бути різними:

1. Безпека та коректність: метод реалізує критично важливу логіку, зміна якої може порушити інваріанти системи
2. Оптимізація: компілятор може виконати девіртуалізацію (devirtualization) — замінити динамічний виклик на прямий, якщо точно відомо, що метод не буде перевизначено
3. Архітектурні обмеження: клас є фінальною реалізацією концепції, подальше наслідування не має сенсу

C++11 додав специфікатор final для цих сценаріїв. final може застосовуватися до:

• Окремих методів — заборона їх перевизначення в похідних класах
• Цілих класів — заборона наслідування

Заборона перевизначення методу

Специфікатор final для методу вказується в тому ж місці, що й override:

#include <iostream>

class Animal
{
public:
    virtual const char* speak() const
    {
        return "???";
    }
};

class Dog : public Animal
{
public:
    const char* speak() const override final  // ✅ Перевизначення, але заборонено далі змінювати
    {
        return "Woof";
    }
};

class Bulldog : public Dog
{
public:
    // ❌ Помилка компіляції: Dog::speak() позначено як final
    const char* speak() const override
    {
        return "Woof-woof";
    }
};

Компілятор видасть помилку:

error: virtual function 'virtual const char* Bulldog::speak() const' overrides final function

Метод Dog::speak() позначено як final, тому клас Bulldog не може його перевизначити.

Заборона наслідування класу

Щоб заборонити наслідування класу, final вказується після імені класу перед списком базових класів (якщо є):

class Animal
{
public:
    virtual const char* speak() const { return "???"; }
};

class Dog final : public Animal  // ✅ Dog не можна наслідувати
{
public:
    const char* speak() const override { return "Woof"; }
};

// ❌ Помилка компіляції: Dog позначено як final
class Bulldog : public Dog
{
public:
    const char* speak() const override { return "Woof-woof"; }
};

Компілятор видасть помилку:

error: cannot derive from 'final' base 'Dog' in derived type 'Bulldog'

Клас Dog позначено як final, тому неможливо створити похідний клас Bulldog.

Коли використовувати final

Оптимізація через девіртуалізацію

Одна з переваг final — можливість компілятора виконати девіртуалізацію. Коли метод або клас позначено як final, компілятор знає, що подальших перевизначень не буде, тому може замінити динамічний виклик через vtable на прямий виклик функції за фіксованою адресою:

class Base
{
public:
    virtual void process() const { /* ... */ }
};

class Derived final : public Base  // Клас позначено як final
{
public:
    void process() const override { /* ... */ }
};

void example(const Derived& obj)
{
    // Компілятор знає, що obj має тип Derived і клас final
    // Виклик може бути девіртуалізовано: замість непрямого виклику через vtable
    // компілятор генерує прямий виклик Derived::process()
    obj.process();
}

У сучасних компіляторах (GCC, Clang, MSVC) девіртуалізація відбувається автоматично для final класів та методів, що покращує продуктивність у критичних ділянках коду.

Віртуальні деструктори: запобігання катастрофічним витокам

Проблема: невіртуальний деструктор у базовому класі

Тепер розглянемо одну з найнебезпечніших проблем поліморфізму в C++ — невіртуальні деструктори. Припустимо, ми створюємо динамічний об'єкт похідного класу та зберігаємо його через покажчик на базовий клас, а потім видаляємо:

#include <iostream>

class Base
{
public:
    Base() { std::cout << "Конструктор Base\n"; }
    ~Base() { std::cout << "Деструктор Base\n"; }  // ❌ НЕ віртуальний!
};

class Derived : public Base
{
private:
    int* data;

public:
    Derived()
    {
        data = new int[1000];  // Виділяємо динамічну пам'ять
        std::cout << "Конструктор Derived (виділено 1000 int)\n";
    }
    
    ~Derived()
    {
        delete[] data;  // Звільняємо пам'ять
        std::cout << "Деструктор Derived (звільнено пам'ять)\n";
    }
};

int main()
{
    Base* ptr = new Derived();  // Створюємо Derived, зберігаємо через Base*
    
    std::cout << "\nВидаляємо об'єкт...\n";
    delete ptr;  // ⚠️ Небезпека!
    
    return 0;
}

Інтуїтивно ми очікуємо, що delete ptr викличе деструктор Derived, який звільнить динамічну пам'ять, а потім деструктор Base. Проте результат виконання шокує:

Деструктор Derived не викликався! Виділена пам'ять (data = new int[1000]) не була звільнена. Це витік пам'яті (memory leak) — одна з найнебезпечніших помилок у C++.

Чому так відбувається

Коли ми виконуємо delete ptr, компілятор аналізує статичний тип покажчика (Base*). Оскільки деструктор Base::~Base() не віртуальний, компілятор генерує код, що викликає лише Base::~Base(), ігноруючи факт, що ptr насправді адресує об'єкт Derived.

Це аналогічно статичному зв'язуванню для звичайних методів: без virtual компілятор орієнтується на тип покажчика, а не на реальний тип об'єкта в пам'яті.

Рішення: віртуальний деструктор

Щоб вирішити цю проблему, достатньо позначити деструктор базового класу як virtual:

#include <iostream>

class Base
{
public:
    Base() { std::cout << "Конструктор Base\n"; }
    virtual ~Base() { std::cout << "Деструктор Base\n"; }  // ✅ Віртуальний!
};

class Derived : public Base
{
private:
    int* data;

public:
    Derived()
    {
        data = new int[1000];
        std::cout << "Конструктор Derived (виділено 1000 int)\n";
    }
    
    ~Derived() override  // ✅ Перевизначення віртуального деструктора
    {
        delete[] data;
        std::cout << "Деструктор Derived (звільнено пам'ять)\n";
    }
};

int main()
{
    Base* ptr = new Derived();
    
    std::cout << "\nВидаляємо об'єкт...\n";
    delete ptr;  // ✅ Тепер коректно!
    
    return 0;
}

Тепер все працює коректно! Деструктор Derived викликається першим, звільняючи динамічну пам'ять, а потім викликається деструктор Base. Це каскадна деструкція — стандартна поведінка віртуальних деструкторів.

Візуалізація проблеми та рішення

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

package "Невіртуальний деструктор (витік пам'яті)" #FECACA {
    participant "Покажчик Base*" as PtrBad #FEE2E2
    participant "Об'єкт Derived" as ObjBad #FED7AA
    participant "Пам'ять (не звільнена)" as MemBad #FCA5A5
    
    PtrBad -> ObjBad : delete ptr
    note over PtrBad #FECACA
      Деструктор Base НЕ віртуальний
      Компілятор викликає лише ~Base()
    end note
    ObjBad -> ObjBad : ~Base()
    note over MemBad #FCA5A5
      Деструктор ~Derived() НЕ викликаний
      Пам'ять data залишається виділеною
      ВИТІК ПАМ'ЯТІ!
    end note
}

package "Віртуальний деструктор (коректна деструкція)" #DCFCE7 {
    participant "Покажчик Base*" as PtrGood #D1FAE5
    participant "Об'єкт Derived" as ObjGood #A7F3D0
    participant "Пам'ять (звільнена)" as MemGood #6EE7B7
    
    PtrGood -> ObjGood : delete ptr
    note over PtrGood #DCFCE7
      Деструктор Base віртуальний
      Runtime викликає ~Derived()
    end note
    ObjGood -> ObjGood : ~Derived()
    note over MemGood #6EE7B7
      delete[] data виконано
      Пам'ять звільнена коректно
    end note
    ObjGood -> ObjGood : ~Base()
    note over ObjGood #A7F3D0
      Каскадний виклик ~Base()
      після ~Derived()
    end note
}
@enduml

Реалістичний приклад: система файлів

Розглянемо реалістичний приклад, де відсутність віртуального деструктора призводить до витоку файлових дескрипторів:

#include <iostream>
#include <fstream>
#include <string>

class FileHandler
{
public:
    virtual void write(const std::string& data) = 0;
    
    // ❌ ПОМИЛКА: деструктор не віртуальний!
    ~FileHandler()
    {
        std::cout << "Деструктор FileHandler\n";
    }
};

class TextFileHandler : public FileHandler
{
private:
    std::ofstream file;
    std::string filename;

public:
    TextFileHandler(const std::string& fname) : filename(fname)
    {
        file.open(filename);
        if (file.is_open()) {
            std::cout << "Відкрито файл: " << filename << "\n";
        }
    }
    
    void write(const std::string& data) override
    {
        if (file.is_open()) {
            file << data << "\n";
        }
    }
    
    ~TextFileHandler() override
    {
        if (file.is_open()) {
            file.close();
            std::cout << "Закрито файл: " << filename << "\n";
        }
    }
};

int main()
{
    FileHandler* handler = new TextFileHandler("log.txt");
    handler->write("Запис даних у файл");
    
    delete handler;  // ⚠️ Файл НЕ закриється, якщо ~FileHandler не віртуальний!
    
    return 0;
}

Якщо деструктор FileHandler не віртуальний, виклик delete handler викличе лише ~FileHandler(), пропустивши ~TextFileHandler(). Файл залишиться відкритим, дескриптор витече, а дані можуть не записатися на диск через буферизацію.

class FileHandler
{
public:
    ~FileHandler() { /* ... */ }  // Не віртуальний
};

// Результат: файл не закривається
// Витік файлового дескриптора

class FileHandler
{
public:
    virtual ~FileHandler() { /* ... */ }  // Віртуальний
};

// Результат: ~TextFileHandler() викликається
// Файл коректно закривається

Синтаксис віртуального деструктора: default vs явна реалізація

Використання = default (C++11)

Якщо деструктор базового класу не виконує жодної спеціальної логіки (не керує ресурсами безпосередньо), найкраща практика — оголосити його як віртуальний через = default:

class Base
{
public:
    virtual ~Base() = default;  // ✅ Віртуальний деструктор за замовчуванням
};

Це явно вказує компілятору: «згенеруй стандартний деструктор, але зроби його віртуальним». Переваги цього підходу:

1. Ясність наміру: код явно вказує, що клас призначений для наслідування
2. Оптимізація: компілятор може згенерувати більш ефективний код, ніж для порожнього ~Base() {}
3. Сумісність із Rule of Zero: якщо клас не керує ресурсами вручну, всі спеціальні члени можна залишити за замовчуванням

Явна реалізація деструктора

Якщо базовий клас безпосередньо керує ресурсами (динамічна пам'ять, файли, мережеві з'єднання), деструктор потрібно реалізувати явно:

class ResourceManager
{
private:
    int* data;

public:
    ResourceManager() : data(new int[100]) {}
    
    virtual ~ResourceManager()  // ✅ Віртуальний з явною реалізацією
    {
        delete[] data;
        std::cout << "Ресурси звільнено\n";
    }
};

Захищений невіртуальний деструктор

Іноді клас призначений лише як базовий для інших класів, але не призначений для видалення через покажчик на базовий клас. У таких випадках деструктор має бути захищеним та невіртуальним:

class NonPolymorphicBase
{
protected:
    ~NonPolymorphicBase() = default;  // ✅ Захищений невіртуальний деструктор

public:
    void sharedLogic() { /* ... */ }
};

class Derived : public NonPolymorphicBase
{
public:
    ~Derived() = default;  // Публічний невіртуальний деструктор
};

int main()
{
    Derived d;  // ✅ Можна створювати локальні об'єкти
    
    // NonPolymorphicBase* ptr = new Derived();
    // delete ptr;  // ❌ Помилка компіляції: ~NonPolymorphicBase() захищений
    
    return 0;
}

Захищений деструктор дозволяє похідним класам викликати його (під час каскадної деструкції), але забороняє видалення через покажчик на базовий клас, усуваючи саму можливість витоку ресурсів.

Вартість віртуального деструктора

Накладні витрати

Віртуальний деструктор має ті самі накладні витрати, що й будь-який віртуальний метод:

1. Покажчик на vtable: кожен об'єкт класу з віртуальними методами зберігає приховані 8 байт (64-бітна система) для покажчика на віртуальну таблицю
2. Непрямий виклик: замість прямого виклику за фіксованою адресою виконується непрямий виклик через vtable

Проте ці витрати мізерні порівняно з катастрофічними наслідками витоків ресурсів. Для класів, призначених для поліморфізму, віртуальний деструктор — обов'язковий, незалежно від накладних витрат.

Коли віртуальний деструктор зайвий

Якщо клас:

• Не має віртуальних методів (не призначений для поліморфізму)
• Є простою структурою даних (POD — Plain Old Data)
• Ніколи не використовується як базовий клас

То віртуальний деструктор зайвий і навіть шкідливий (збільшує розмір об'єкта без потреби):

// ❌ Не робіть це — Point не призначений для наслідування
struct Point
{
    double x, y;
    virtual ~Point() = default;  // Зайвий віртуальний деструктор
};

// sizeof(Point) стане 24 байти замість 16 байт
// (8 байт x + 8 байт y + 8 байт vptr)

Порівняльна таблиця: віртуальний vs невіртуальний деструктор

Коваріантні типи повернення: гнучкість перевизначення

Спеціальний випадок: повернення покажчика на похідний клас

Раніше ми згадували, що тип повернення перевизначення має збігатися з типом повернення базового методу. Проте є важливий виняток: коваріантні типи повернення (covariant return types).

Якщо базовий віртуальний метод повертає покажчик або посилання на клас Base, перевизначення в похідному класі може повертати покажчик або посилання на клас Derived:

#include <iostream>

class Animal
{
public:
    virtual ~Animal() = default;
    
    // Повертає Animal*
    virtual Animal* clone() const
    {
        std::cout << "Клонування Animal\n";
        return new Animal(*this);
    }
};

class Dog : public Animal
{
public:
    // ✅ Коваріантний тип повернення: Dog* замість Animal*
    Dog* clone() const override
    {
        std::cout << "Клонування Dog\n";
        return new Dog(*this);
    }
};

class Cat : public Animal
{
public:
    Cat* clone() const override
    {
        std::cout << "Клонування Cat\n";
        return new Cat(*this);
    }
};

int main()
{
    Dog barsik;
    Cat murka;
    
    // Пряме звернення: отримуємо Dog* без приведення типів
    Dog* barsikClone = barsik.clone();
    
    // Через покажчик на базовий клас: повертається Animal*
    Animal* animalPtr = &murka;
    Animal* murkaClone = animalPtr->clone();  // Фактично створюється Cat
    
    delete barsikClone;
    delete murkaClone;
    
    return 0;
}

Коваріантні типи повернення зручні для патернів проєктування, таких як фабричний метод (Factory Method) або прототип (Prototype), де метод створює та повертає копію об'єкта. Без коваріантних типів довелося б виконувати явне приведення типів:

Dog barsik;
Dog* clone = barsik.clone();  // ✅ Природно

Dog barsik;
Dog* clone = static_cast<Dog*>(barsik.clone());  // ❌ Незручно

class Base {
    virtual Base getValue();  // Повернення за значенням
};

class Derived : public Base {
    Derived getValue() override;  // ❌ Помилка: коваріантність працює лише для покажчиків/посилань
};

Практичні рекомендації та чеклист

Резюме

У цій статті ми опанували інструменти C++11, які роблять роботу з поліморфізмом безпечнішою та зрозумілішою:

Ключове правило, яке слід запам'ятати:

Якщо клас має хоча б один віртуальний метод, його деструктор має бути публічним віртуальним або захищеним невіртуальним (якщо поліморфне видалення не передбачається).

У наступній статті ми заглибимося в внутрішні механізми поліморфізму: як компілятор реалізує динамічне зв'язування через віртуальні таблиці (vtable), що таке покажчик на віртуальну таблицю (vptr), і чому віртуальні функції не працюють у конструкторах та деструкторах.

class Shape
{
public:
    virtual double getArea() const = 0;
    virtual void draw() const { /* ... */ }
    virtual ~Shape() = default;
};

class Circle : public Shape
{
private:
    double radius;

public:
    Circle(double r) : radius(r) {}
    
    // Намагаємося перевизначити getArea
    double getArea() { return 3.14159 * radius * radius; }
    
    // Намагаємося перевизначити draw
    void draw() { /* ... */ }
};

class Shape
{
public:
    virtual double getArea() const = 0;
    virtual void draw() const { /* ... */ }
    virtual ~Shape() = default;
};

class Circle : public Shape
{
private:
    double radius;

public:
    Circle(double r) : radius(r) {}
    
    // ✅ Виправлено: додано const та override
    double getArea() const override
    {
        return 3.14159 * radius * radius;
    }
    
    // ✅ Виправлено: додано const та override
    void draw() const override { /* ... */ }
};