Для чего нужен виртуальный деструктор. И в каких случаях он необходим.

Здравствуйте, Аноним, Вы писали:

А>Для чего нужен виртуальный деструктор. И в каких случаях он необходим.

Виртуальные функции (и деструктор в частности) в С++ нужны для того, чтобы вызывать перегруженный в классе-потомке вариант соотв. функции через указатель на базовый класс. Применительно к деструктору это означает, что объект класса-потомка D можно корректно удалить, имея указатель на базовый класс B:

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

...

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

...

B * pObj = new D;

...

delete pObj; // - если бы не virtual ~B(), ~D() не вызвался бы.

подробнее — у Страуструпа.

Здравствуйте, Аноним, Вы писали:

А>Для чего нужен виртуальный деструктор. И в каких случаях он необходим.

Для того же для чего и виртуальные функции :) Чтобы вызывался деструктор реального типа класса, а не типа класса на который указывает ссылка

Здравствуйте, Stuw, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>Для чего нужен виртуальный деструктор. И в каких случаях он необходим.

S>Для того же для чего и виртуальные функции Чтобы вызывался деструктор реального типа класса, а не только типа класса на который указывает указатель

Поправочка.

Если деструктор базового класса виртуальный, и ты удаляешь объект производного класса через указатель на этот базовый класс, то вызов деструкторов будет таким же, как в случае автоматического вызова деструкторов — сначала вызовется деструктор производного класса, потом базового. При таких же дейтсвиях без виртуального д. базового класса деструктор производного класса не вызовется(UB, неопределенное поведение), а вызовется только деструктор базового класса. Важно, что такое поведение характерно только для удаления потомков через указатель на базовый класс.

Виртуальный деструктор необходим тогда, когда ты собираешься удалять объекты производных классов через указатели на базовые. Во всех остальных случаях виртуальность необязательна. За подробностями к Саттеру

Здравствуйте, Константин Л., Вы писали:

КЛ> За подробностями к Саттеру
Или к Майерсу.

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

Здравствуйте, Аноним, Вы писали:
А> сорри, а для чего практически нужны виртуальные функции? т.е. не не рассказывайте про какой-нить
А> академический пример, а в реальной практике в какой ситуации вирт. функции могут быть полезны и быть
А> более эффективны, чем использование обычных функций?

Примеров — как говорицца море — первое что приходит на ум — векторный графический редакток в котором все отображаемые граф. объекты представляются потомками одного класса — Shape например который имеет виртуальную функцию для отрисовки — draw — и реализуем для каждого из потомков (Circle, Quad...) — только свою функцию отрисовки — о все остальное — функции перемещения, свойства для цвета фона, границы и т.д. — реализовать в базовом классе.

Преимущества:
1. уменьшее размера кода (существенное
2. повышение структурированности приложения
3. повышение скорости разработки

Здравствуйте, Аноним, Вы писали:

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

#include <iostream>

(эта библиотека, кроме того, иллюстрирует еще один хороший принцип — NVI)

Во многих управляемых языках (Java) все вызовы виртуальные. В COM все вызовы виртуальные. (AFAIR)

A>Примеров — как говорицца море — первое что приходит на ум — векторный графический редакток в котором все отображаемые граф. объекты представляются потомками одного класса — Shape например который имеет виртуальную функцию для отрисовки — draw — и реализуем для каждого из потомков (Circle, Quad...) — только свою функцию отрисовки — о все остальное — функции перемещения, свойства для цвета фона, границы и т.д. — реализовать в базовом классе.

хорошо. но то же самое можно сделать и без вирт функций. т.е. базовый класс с общими вещами, наследники с отрисовкой. просто будет функция отрисовки потомков не виртуальная. в чём тут недостаток будет?

A>Преимущества:
A>1. уменьшее размера кода (существенное
то же самое будет

A>2. повышение структурированности приложения
то же самое будет

A>3. повышение скорости разработки
то же самое будет

Здравствуйте, Аноним, Вы писали:

А> хорошо. но то же самое можно сделать и без вирт функций. т.е. базовый класс с общими вещами, наследники с отрисовкой. просто будет функция отрисовки потомков не виртуальная. в чём тут недостаток будет?
Смотри сюда... Тут без виртуальности — ну никак!

Зачем нужны виртуальные функции
При наследовании часто бывает необходимо, чтобы поведение некоторых методов базового класса и классов-наследников отличались. Решение, на первый взгляд, очевидное: переопределить соответствующие методы в производном классе. Однако тут возникает одна проблема, которую лучше рассмотреть на простом примере (листинг 9.1).

//Листинг 9.1. Необходимость виртуальных функций
#include <iostream>
using namespace std;
class Base                                 // базовый класс
{  public:
    int f(const int &d)                    // метод базового класса
    { return 2*d; }
    int CallFunction(const int &d)         // предполагается
    { return f(d)+1;                       // вызов метода базового класса
    }
};
class Derived: public Base                 // производный класс
{  public:                                 // CallFunction наследуется
    int f(const int &d)                    // метод f переопределяется
    { return d*d; }
};
int main()
{   Base a;                                // объект базового класса
    cout << a.CallFunction(5)<< endl;      // получаем 11
    Derived b;                             // объект производного власса
    cout << b.CallFunction(5)<< endl;      // какой метод f вызывается?
    return 0;
}

В базовом классе определены два метода — f() и CallFunction(), — причем во втором методе вызывается первый. В классе-наследнике метод f() переопределен, а метод CallFunction() унаследован. Очевидно, метод f() переопределяется для того, чтобы объекты базового класса и класса-наследника вели себя по-разному. Объявляя объект b типа Derived, программист, естественно, ожидает получить результат 5 * 5 + 1 = 26 — для этого и переопределялся метод f(). Однако на экран, как и для объекта а типа Base, выводится число 11, которое очевидно вычисляется как 2 * 5 + 1 = 11. Несмотря на переопределение метода f() в классе-наследнике, в унаследованной функции CallFunction() вызывается «родная» функция f(), определенная в базовом классе!
Аналогичная проблема возникает и в несколько другом контексте: при подстановке ссылки или указателя на объект производного класса вместо ссылки или указателя на объект базового. Рассмотрим опять пример с часами и будильником (листинг 9.2).

//Листинг 9.2. Неожиданная работа принципа подстановки
class Clock               // базовый класс — часы
{ public:
    void print() const { cout << "Clock!" << endl; }
};
class Alarm: public Clock // производный класс — будильник
{ public:
    void print() const    // переопределенный метод
    { cout << "Alarm!" << endl; }
};
void settime(Clock &d)    // функция установки времени
{ d.print(); }            // предполагается вызов метода базового класса
//...
Clock W;                  // объект базового класса
settime(W);               // выводится "Clock"
Alarm U;                  // объект производного класса
settime(U);               // ссылка на производный вместо базового 
Clock *c1 = &W;           // адрес объекта базового класса
c1->print();              // вызов базового метода 
c1 = &U;                  // адрес объекта производного типа вместо базового
c1->print();              // какой метод вызываетя, базовый или производный?

Опять в классе-наследнике переопределен метод для того, чтобы обеспечить различное поведение объектов базового и производного классов. Однако и при передаче параметра по ссылке базового класса в функцию settime(), и при явном вызове метода print() через указатель базового класса наблюдается одна и та же картина: всегда вызывается метод базового класса, хотя намерения программиста состоят в том, чтобы вызвать метод производного.
Для того чтобы разобраться в ситуации, необходимо уяснить, что такое связывание. Связывание — это сопоставление вызова функции с телом. В приведенных ранее примерах связывание выполняется на этапе трансляции (до запуска) программы. Такое связывание обычно называют ранним, или статическим.

При трансляции класса Base (см. листинг 9.1) компилятор ничего не знает о классах-наследниках , поэтому он не может предполагать, что метод f() будет переопределен в классе Derived. Его естественное поведение — «прочно» связать вызов f() с телом метода класса Base. Аналогично при трансляции функции settime() компилятору ничего не известно о типе реально передаваемого объекта во время выполнения программы. Поэтому вызов метода print() связывается с телом метода базового класса Clock, как и определено в заголовке функции settime(). Точно так же указатель на базовый класс «прочно» связывается с методом базового класса во время трансляции.
Конечно, при вызове метода по указателю в данном конкретном случае мы можем вызвать метод производного класса, задав явное преобразование указателя:

static_cast<Alarm*>(c1)->print();

Или так:

((Alarm *)c1)->print();                // "лишние" скобки нужны!

Однако для функции settime() и метода CallFunction() это сделать невозможно — нам необходимо именно разное поведение в зависимости от типа объекта. Да и с указателем не все так просто: если такой вызов прописан внутри функции, которая принимает этот указатель как параметр (например, settime(Clock *c1)), то мы имеем те же проблемы.
Определение виртуальных функций
Получается, что в С++ должен существовать механизм, с помощью которого можно узнать тип объекта во время выполнения программы. Такой механизм в С++ есть и он, как уже отмечалось, называется динамической идентификацией типов (RTTI). Однако в ситуациях, подобных описанным, применяется другой, более «сильный» и элегантный механизм С++ — механизм виртуальных функций (см. п. 10.3 в Стандарте).
Чтобы добиться разного поведения в зависимости от типа, необходимо объявить функцию-метод виртуальной; в С++ это делается с помощью ключевого слова virtual. Таким образом, в листинге 9.1 объявление метода f() в базовом и производном классе должно быть таким:

virtual int f(const int &d)                // в базовом классе
            { return 2*d; }
virtual int f(const int &d)                // в производном классе
            { return d*d; }

После этого для объектов базового и производного классов мы получаем разные результаты: 11 и 26.
Аналогично в листинге 9.2 объявление метода print() тоже должно начинаться со слова virtual:

irtual    void print() const              // в базовом классе
{ cout << "Clock!" << endl; }
virtual    void print() const              // в производном классе
{ cout << "Alarm!" << endl; }

После этого вызов settime() с параметром базового класса обеспечит нам вывод на экран слова «Clock», а с параметром производного класса — слова «Alarm». И при вызове по указателю наблюдается та же картина.
Вообще-то ключевое слово virtual достаточно написать только один раз — в объявлении функции базового класса. Определение можно писать без слова virtual — все равно функция будет считаться виртуальной. Однако лучше всегда это делать явным образом, чтобы всегда по тексту было видно, что функция является виртуальной.
Для виртуальных функций обеспечивается не статическое, а динамическое (позднее, отложенное) связывание, которое реализуется во время выполнения программы. Естественно, это влечет за собой некоторые накладные расходы, однако на них можно не обращать внимания, так как обеспечивается динамический полиморфизм. Александреску указывает, что в С++ реализованы два типа полиморфизма:

• статический полиморфизм, или полиморфизм времени компиляции (compile-time polymorphism), осуществляется за счет перегрузки и шаблонов функций;
  
• динамический полиморфизм, или полиморфизм времени выполнения (run-time polymorphism), реализуется виртуальными функциями.

С перегрузкой функций «разбирается» компилятор, правильно подбирая вариант функции в той или иной ситуации. И полиморфизм шаблонных функций тоже реализуется на этапе компиляции. Естественно, выбор осуществляется статически. Выбор же виртуальной функции происходит динамически — при выполнении программы. Класс, включающий виртуальные функции, называется полиморфным.
Правила описания и использования виртуальных функций-методов следующие:
1. Виртуальная функция может быть только методом класса.
2. Любую перегружаемую операцию-метод класса можно сделать виртуальной, например, операцию присваивания или операцию преобразования типа.
3. Виртуальная функция, как и сама виртуальность, наследуется.
4. Виртуальная функция может быть константной.
5. Если в базовом классе определена виртуальная функция, то метод производного класса с такими же именем и прототипом (включая тип возвращаемого значения и константность метода) автоматически является виртуальным (слово virtual указывать необязательно) и замещает функцию-метод базового класса.
6. Конструкторы не могут быть виртуальными.
7. Статические методы не могут быть виртуальными.
8. Деструкторы могут (чаще — должны) быть виртуальными — это гарантирует корректный возврат памяти через указатель базового класса.

Здравствуйте, <Аноним>, Вы писали:

А> хорошо. но то же самое можно сделать и без вирт функций. т.е. базовый класс с общими вещами, наследники с отрисовкой. просто будет функция отрисовки потомков не виртуальная. в чём тут недостаток будет?

Так или иначе придётся отсылаться к реализациям функций потомков из базового. Это можно сделать:
— pattern matching'ом — попросту, нагородить ветвлений (if, switch/case) по значению тэга, определённого в базе и установленного потомком
— указателями на функции (полями базы, опять же установленными потомком)
— перекрытыми виртуальными функциями (те же указатели, но всё сделано компилятором и положено в VMT)