Конструкторы и деструкторы

9.4.1 Конструкторы и деструкторы

Описанный способ управления ресурсами обычно называют "запрос ресурсов

путем инициализации". Это универсальный прием, рассчитанный на

свойства конструкторов и деструкторов и их взаимодействие с

механизмом особых ситуаций.

Объект не считается построенным, пока не завершил выполнение его

конструктор. Только после этого возможна раскрутка стека,

сопровождающая вызов деструктора объекта. Объект, состоящий из

вложенных объектов, построен в той степени, в какой построены

вложенные объекты.

Хорошо написанный конструктор должен гарантировать, что объект

построен полностью и правильно. Если ему не удается сделать это,

он должен, насколько это возможно, восстановить состояние системы,

которое было до начала построения. Для простых конструкторов было бы

идеально всегда удовлетворять хотя бы одному условию - правильности

или законченности объектов, и никогда не оставлять объект

в "наполовину построенном" состоянии. Этого можно добиться, если

применять при построении членов способ "запроса ресурсов путем

инициализации".

Рассмотрим класс X, конструктору которого требуется два ресурса:

файл x и замок y (т.е. монопольные права доступа к чему-либо).

Эти запросы могут быть отклонены и привести к запуску особой

ситуации. Чтобы не усложнять работу программиста, можно потребовать,

чтобы конструктор класса X никогда не завершался тем, что запрос на

файл удовлетворен, а на замок нет. Для представления двух видов

ресурсов мы будем использовать объекты двух классов FilePtr и

LockPtr (естественно, было бы достаточно одного класса, если x и y

ресурсы одного вида). Запрос ресурса выглядит как инициализация

представляющего ресурс объекта:
class X {

FilePtr aa;

LockPtr bb;

// ...

: aa(x), // запрос `x'

bb(y) // запрос `y'

{ }

};
Теперь, как это было для случая локальных объектов, всю служебную

работу, связанную с ресурсами, можно возложить на реализацию.

Пользователь не обязан следить за ходом такой работой. Например,

если после построения aa и до построения bb возникнет особая

ситуация, то будет вызван только деструктор aa, но не bb.

Это означает, что если строго придерживаться этой простой

схемы запроса ресурсов, то все будет в порядке. Еще более важно

то, что создателю конструктора не нужно самому писать обработчики

особых ситуаций.

Для требований выделить блок в свободной памяти характерен самый

произвольный порядок запроса ресурсов. Примеры таких запросов уже

неоднократно встречались в этой книге:
class X {

int* p;

public:

~X() { delete[] p; }

// ...

};
Это типичный пример использования свободной памяти, но в совокупности с

Действительно, если в init() запущена особая ситуация, то отведенная

память не будет освобождена. Деструктор не будет вызываться, поскольку

построение объекта не было завершено. Есть более надежный вариант

этого примера:
template class MemPtr {

public:

MemPtr(size_t s) { p = new T[s]; }

~MemPtr() { delete[] p; }

operator T*() { return p; }

}
class X {

MemPtr cp;

// ...

public:

// ...

в MemPtr. Если init() запустит особую ситуацию, отведенная память

будет освобождена при неявном вызове деструктора для полностью

построенного вложенного объекта cp.

Отметим также, что стандартная стратегия выделения памяти в С++

гарантирует, что если функции operator new() не удалось выделить память

для объекта, то конструктор для него никогда не будет вызываться. Это

означает, что пользователю не надо опасаться, что конструктор или

деструктор может быть вызван для несуществующего объекта.

Теоретически дополнительные расходы, требующиеся для обработки

особых ситуаций, когда на самом деле ни одна из них не возникла, могут

быть сведены к нулю. Однако, вряд ли это верно для ранних

реализациях языка. Поэтому будет разумно в критичных внутренних циклах

программы пока не использовать локальные переменные классов

с деструкторами.

9.4.2 Предостережения

Не все программы должны быть устойчивы ко всем видам ошибок. Не все

ресурсы являются настолько критичными, чтобы оправдать попытки

защитить их с помощью описанного способа "запроса ресурсов путем

инициализации". Есть множество программ, которые просто читают

входные данные и выполняются до конца. Для них самой подходящей

реакцией на динамическую ошибку будет просто прекращение счета

(после выдачи соответствующего сообщения). Освобождение всех

затребованных ресурсов возлагается на систему, а пользователь

должен произвести повторный запуск программы с более подходящими

входными данными. Наша схема предназначена для задач, в которых

такая примитивная реакция на динамическую ошибку неприемлема.

Например, разработчик библиотеки обычно не в праве делать допущения

о том, насколько устойчива к ошибкам, должна быть программа,

работающая с библиотекой. Поэтому он должен учитывать все динамические

ошибки и освобождать все ресурсы до возврата из библиотечной функции

в пользовательскую программу. Метод "запроса ресурсов путем

инициализации" в совокупности с особыми ситуациями, сигнализирующими

об ошибке, может пригодиться при создании многих библиотек.