Стандарты программирования на С++. 101 правило и рекомендация

Написание базового класса представляет собой определение абстракции (см. рекомендации с 35 по 37). Вспомним, что для каждой функции-члена, участвующей в абстракции, вы должны решить:

• должна ли она вести себя виртуально или нет;

• должна ли она быть открыто доступна всему вызывающему коду посредством указателя на Base или она должна представлять собой скрытую внутреннюю деталь реализации.

Как описано в рекомендации 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) или функции обмена. В частности, типы, деструкторы которых могут генерировать исключения, категорически запрещено использовать со стандартной библиотекой С++.

Обсуждение

Перечисленные функции не должны генерировать исключений, так как они являются ключевыми для двух главных операций транзакционного программирования — отката при возникновении проблем в процессе работы и принятия результата работы, если проблем не возникло. Если нет способа безопасного возврата в предыдущее состояние при помощи операций, не генерирующих исключения, то невозможно реализовать бессбойный откат; отсутствие возможности безопасного сохранения изменения состояния при помощи операции, не генерирующей исключения, делает невозможной реализацию бессбойного принятия результата работы.

Рассмотрим следующие советы и требования, найденные в Стандарте С++.

Если деструктор, вызванный в процессе свертки стека, выходит с исключением, вызывается функция terminate (15.5.1). Поэтому деструкторы должны в общем случае перехватывать исключения и не позволять им распространиться за пределы деструктора.

— [C++03] §15.2(3)

В стандартной библиотеке C++ не определен ни один деструктор [включая деструкторы любого типа, используемого для инстанцирования шаблона стандартной библиотеки], генерирующий исключение.

— [C++03] §17.4.4.8(3)

Деструкторы являются специальными функциями, и компилятор автоматически вызывает их в различных контекстах. Если вы пишете класс — назовем его, к примеру, Nefarious [2] — деструктор которого может давать сбой (обычно посредством генерации исключения; см. рекомендацию 72), то вы столкнетесь с такими последствиями.

• Объекты Nefarious трудно безопасно использовать в обычных функциях. Вы не можете надежно инстанцировать автоматические объекты Nefarious в области видимости, если возможен выход из этой области видимости посредством исключения. Если это произойдет, деструктор Nefarious (вызываемый автоматически) может попытаться сгенерировать исключение, которое приведет к неожиданному завершению всей программы посредством вызова Терминатора — std::terminate (см. также рекомендацию 75).

2

Nefarious — нечестивый, гнусный (англ.). — Прим. перев.