Как описано в рекомендации 39, для обычных функций-членов следует сделать выбор между возможностью их вызова посредством указателя Base* невиртуально (но, возможно, с виртуальным поведением, если эти функции вызывают виртуальные функции, как, например, в шаблонах проектирования NVI или Template Method), виртуально либо невозможностью такого вызова вообще. Шаблон проектирования NVI представляет собой методику, которая позволяет обойтись без открытых виртуальных функций.

Деструкция может рассматриваться как просто одна из операций, хотя и со специальной семантикой, которая делает невиртуальные вызовы опасными или ошибочными. Следовательно, для деструктора базового класса выбор сужается до виртуального вызова через указатель Base* или невозможности вызова вообще; выбор невиртуального вызова в данном случае неприменим. Следовательно, деструктор базового класса виртуален, если он может быть вызван (т.е. открыт), и невиртуален в противном случае.

Заметим, что шаблон проектирования NVI не может быть применен к деструктору, поскольку конструкторы и деструкторы не могут осуществлять глубокие виртуальные вызовы (см. рекомендации 39 и 55).

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

Примеры

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

• Пример 1. Базовые классы с полиморфным удалением. Если должно быть разрешено полиморфное удаление, то деструктор должен быть открытым (в противном случае вызывающий код не сможет к нему обратиться) и должен быть виртуальным (в противном случае его вызов приведет к неопределенному поведению).

• Пример 2. Базовые классы без полиморфного удаления. Если полиморфное удаление не должно быть разрешено, деструктор должен не быть открытым (чтобы вызывающий код не мог к нему обратиться) и не должен быть виртуальным (потому что виртуальность ему не нужна).

Классы стратегий часто используются в качестве базовых для удобства, а не для обеспечения полиморфного поведения. Их деструкторы рекомендуется делать защищенными и невиртуальными.

Исключения

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

Рассмотрим также еще один редкий случай.

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

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

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

В этом редком случае вы можете сделать конструктор открытым и невиртуальным, но четко документировать, что производные объекты не могут использоваться полиморфно в качестве объектов базового класса. Именно это было сделано в случае класса std::unary_function.

В общем случае, однако, следует избегать конкретных базовых классов (см. рекомендацию 35). Например, unary_function представляет собой набор определений typedef, который не предназначен для создания объектов данного типа. В действительности бессмысленно давать ему открытый деструктор; лучше было бы последовать совету данной рекомендации и сделать его деструктор защищенным и невиртуальным.

Ссылки

[Cargill92] pp. 77-79, 207 • [Cline99] §21.06, 21.12-13 • [Henricson97] pp. 110-114 • [Koenig97] Chapters 4,11 • [Meyers97] §14 • [Stroustrup00] §12.4.2 • [Sutter02] §27 • [Sutter04] § 18

51. Деструкторы, функции освобождения ресурсов и обмена не ошибаются

Резюме

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

Обсуждение