Что произойдет, если я изменю деструктор одного базового класса с невиртуального на виртуальный?

Виртуальность деструктора ничего не сломает в существующем коде, если нет других проблем. Это может даже решить некоторые (см. Ниже). Однако класс не может быть разработан как полиморфный, поэтому добавление virtual к его деструктору делает его способным к полиморфизму, что может быть нежелательно. Тем не менее, вы должны иметь возможность безопасно добавлять виртуальность к деструктору, и он не должен вызывать никаких проблем сам по себе.

Объяснение

Полиморфизм позволяет:

class A 
{
public:
    ~A() {}
};

class B : public A
{
    ~B() {}

    int i;
};

int main()
{
    A *a = new B;
    delete a;
}

Вы можете взять указатель на объект типа A из класса, который на самом деле имеет тип B. Это полезно, например, для разделения интерфейсов (например, A) и реализаций (например, B). Однако что будет на delete a;?

Часть объекта a типа A уничтожена. А как насчет части типа B? К тому же у этой части есть ресурсы, и их нужно освободить. Ну вот тут и утечка памяти. Вызывая delete a;, вы вызываете деструктор типа A (поскольку a является указателем на тип A), в основном вы вызываете a->~a();. Деструктор типа B никогда не вызывается. Как это решить?

class A :
{
public:
    virtual ~A() {}
};

Добавляя виртуальную диспетчеризацию к деструктору A (обратите внимание, что, объявляя базовый деструктор виртуальным, он автоматически делает деструкторы всех производных классов виртуальными, даже если они не объявлены как таковые). Затем вызов delete a; отправит вызов деструктора в виртуальную таблицу, чтобы найти правильный деструктор для использования (в данном случае типа B). Этот деструктор будет вызывать родительские деструкторы как обычно. Аккуратно, правда?

Возможные проблемы

Как видите, таким образом вы ничего не сломаете. Однако в вашем дизайне могут быть другие проблемы. Например, могла быть ошибка, которая «полагалась» на невиртуальный вызов деструктора, который вы раскрыли, сделав его виртуальным, рассмотрим:

int main()
{
    B *b = new B;
    A *a = b;
    delete a;
    b->i = 10; //might work without virtual destructor, also undefined behvaiour
}

В основном нарезка объекта, но поскольку до этого у вас не было виртуального деструктора, B часть созданного объекта не была уничтожена, поэтому назначение i может сработать. Если вы сделали деструктор виртуальным, то он не существует и, скорее всего, выйдет из строя или сделает что-то еще (неопределенное поведение).

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

Взгляните здесь,

struct Component {
    int* data;

    Component() { data = new int[100]; std::cout << "data allocated\n"; }
    ~Component() { delete[] data; std::cout << "data deleted\n"; }
};

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

struct Derived : Base {
    Component c;
    void f() override {}

};

int main()
{
    Base* b = new Derived;
    delete b;
}

Выход:

данные распределены

но не удален.

Вывод

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

Возможно, что после того, как вы добавили этот виртуальный деструктор в свой класс, вы запустили непроверенную логику уничтожения. Разумный выбор здесь - сохранить виртуальный деструктор, который вы добавили, и исправить логику. В противном случае в вашем процессе могут возникнуть утечки ресурсов и / или памяти.

Технические детали

В этом примере происходит то, что, хотя Base имеет vtable, сам его деструктор не является виртуальным, и это означает, что всякий раз, когда вызывается Base::~Base(), он не проходит через vptr < / em>. Другими словами, он просто вызывает Base::Base(), и все.