Правило 13: Используйте объекты для управления ресурсами

Правило 13: Используйте объекты для управления ресурсами

Предположим, что мы работаем с библиотекой, моделирующей инвестиции (то есть акции, облигации и т. п.), и классы, представляющие разные виды инвестиций, наследуются от корневого класса Investment:

class Investment {...} // корневой класс иерархии

// типов инвестиций

Предположим далее, что библиотека предоставляет объекты, описывающие конкретные инвестиции, с помощью фабричной функции (см. правило 7):

Investment *createInvestment(); // возвращает указатель на динамически

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

// Investment: вызвавший клиент обязан

// удалить его (параметры для простоты

// опущены)

Как следует из комментария, пользователь, вызвавший createlnvestment, отвечает за удаление объекта, возвращенного этой функцией, по окончании его использования. Рассмотрим теперь функцию f, которая это делает:

void f()

{

Investment *pInv = createInvestment(); // вызвать фабричную функцию

... // использовать pInv

delete pInv; // освободить память, занятую

} // объектом

Выглядит хорошо, но есть несколько случаев, когда f не удастся удалить объект инвестиций, полученный от createlnvestment. Где-нибудь внутри непоказанной части функции может встретиться предложение return. Если такой возврат будет выполнен, то управление никогда не достигнет оператора delete. Похожая ситуация может случиться, если вызов createlnvestment и delete поместить в в цикл, и этот цикл будет прерван в результате выполнения goto или continue. И наконец, некоторые предложения внутри части, обозначенной «…», могут возбудить исключение. И в этом случае управление не дойдет до оператора delete. Независимо от того, почему delete будет пропущен, мы потеряем не только память, выделенную для объекта Investment, но и все ресурсы, которые он захватил.

Конечно, тщательное программирование может предотвратить ошибки подобного рода, но подумайте о том, как может измениться код со временем. При сопровождении программы кто-то может добавить предложение return или continue, не вполне понимая последствий своих действий для стратегии управления ресурсами, реализованной в данной функции. Хуже того, часть «…» функции f может вызвать функцию, которая никогда не возбуждала исключений, но начнет это делать после некоторого «усовершенствования». То есть полагаться на то, что f всегда доберется до своего оператора delete, просто нельзя.

Чтобы обеспечить освобождение ресурса, возвращенного createlnvestment, нам нужно инкапсулировать ресурс внутри объекта, чей деструктор автоматически освободит его, когда управление покинет функцию f. Фактически это половина идеи дела: заключая ресурс в объект, мы можем положиться на автоматический вызов деструкторов C++, чтобы гарантировать их освобождение. (Вторую половину мы обсудим чуть ниже.)

Многие ресурсы динамически выделяются из «кучи», используются внутри одного блока или функции и должны быть освобождены, когда управление покидает этот блок или функцию. Для таких ситуаций предназначен класс стандартной библиотеки auto_ptr. Класс auto_ptr описывает объект, подобный указателю (интеллектуальный указатель), чей деструктор автоматически вызывает delete для того, на что он указывает. Вот как использовать auto_ptr для предотвращения потенциальной опасности утечки ресурсов в нашей функции f:

void f()

{

std::auto_ptr<Investment> pInv(createInvestment()); // вызов фабричной

// функции

... // использование pInv как раньше

} // автоматическое удаление pInv

// деструктором auto_ptr

Этот простой пример демонстрирует два наиболее существенных аспекта применения объектов для управления ресурсами:

• Ресурс захватывается и сразу преобразуется объект, управлящий им. В приведенном примере ресурс, возвращенный функцией createInvestment, используется для инициализации auto_ptr, который будет им управлять. Фактически идею использования объектов для управления ресурсами часто называют Получение Ресурса Есть Инициализация (Resource Acquisition Is Initialization – RAII), поскольку нередко приходится получать ресурс и инициализировать объект управления ресурсом в одном и том же предложении. Иногда полученные ресурсы присваиваются управляющему объекту вместо инициализации, но в любом случае каждый ресурс сразу после получения преобразуется в управляющий им объект.

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

Так как деструктор auto_ptr автоматически удаляет то, на что указывает, важно, чтобы ни в какой момент времени не существовало более одного auto_ptr, указывающего на один и тот же объект. Если такое случается, то объект будет удален более одного раза, что обязательно приведет к неопределенному поведению. Чтобы предотвратить такие проблемы, объекты auto_ptr обладают необычным свойством: при копировании (посредством копирующих конструкторов или операторов присваивания) внутренний указатель в старом объекте становится равным нулю, а новый объект получает ресурс в свое монопольное владение!

std::auto_ptr<Investment> // pInv1 указывает на объект,

pInv1(createInvestment()); // возвращенный createInvestment()

std::auto_ptr<Investment> pInv2(pInv1); // pInv2 теперь указывает на объект,

// а pInv1 равен null

pInv1 = pInv2; // теперь pInv1 указывает на объект,

// а pInv2 равно null

Это странное поведение при копировании плюс лежащее в его основе требование о том, что ни на какой ресурс, управляемый auto_ptr, не должен указывать более чем один auto_ptr, означает, что auto_ptr – не всегда является наилучшим способом управления динамически выделяемыми ресурсами. Например, STL-контейнеры требуют, чтобы их содержимое при копировании вело себя «нормально», поэтому помещать в них объекты auto_ptr нельзя.

Альтернатива auto_ptr – это интеллектуальные указатели с подсчетом ссылок (reference-counting smart pointer – RCSP). RCSP – это интеллектуальный указатель, который отслеживает, сколько объектов указывают на определенный ресурс, и автоматически удаляет ресурс, когда никто на него не ссылается. Следовательно, RCSP ведет себя подобно сборщику мусора. Но, в отличие от сборщика мусора, RCSP не может разорвать циклические ссылки (когда два неиспользуемых объекта указывают друг на друга).

Класс tr1::shared_prt из библиотеки TR1 (см. правило 54) – это типичный пример RCSP, поэтому вы можете написать:

void f()

{

...

std::tr1::shared_ptr<Investment>

pInv(createStatement()); // вызвать фабричную функцию

... // использовать pInv как раньше

} // автоматически удалить pInv

// деструктором shared_ptr

Этот код выглядит почти так же, как и использующий auto_ptr, но shared_ptr при копировании ведет себя гораздо более естественно:

void f()

{

...

std::tr1::shared_ptr<Investment> // pInv1 указывает на объект,

pInv1(createStatement()); // возвращенный createInvestment

std::tr1::shared_ptr<Investment> // теперь оба объекта pInv1 и pInv2

pInv2(pInv1); // указывают на объект

pInv1 = pInv2; // ничего не изменилось

...

} // pInv1 и pInv2 уничтожены, а объект,

// на который они указывали,

// автоматически удален

Поскольку копирование объектов tr1::shared_ptr работает «как ожидается», то они могут быть использованы в качестве элементов STL-контейнеров, а также в других случаях, когда непривычное поведение auto_ptr нежелательно.

Однако не заблуждайтесь. Это правило посвящено не auto_ptr и tr1::shared_ptr, или любым другим типам интеллектуальных указателей. Здесь мы говорим о важности использования объектов для управления ресурсами. auto_ptr и tr1::shared_ptr – всего лишь примеры объектов, которые делают это. (Более подробно о tr1::shared_ptr читайте в правилах 14, 18 и 54.)

И auto_ptr, и tr1::shared_ptr в своих деструкторах используют оператор delete, а не delete[]. (Разница между ними описана в правиле 16.) Это значит, что нельзя применять auto_ptr и tr1::shared_ptr к динамически выделенным массивам, хотя, как это ни прискорбно, следующий код скомпилируется:

std::auto_ptr<std::string> // плохая идея! Будет

aps(new std::string[10]); // использована не та форма

// оператора delete

std::tr1::shared_ptr<int> spi(new int[1024]); // та же проблема

Вас может удивить, что не предусмотрено ничего подобного auto_ptr или tr1::shared_ptr для работы с динамически выделенными массивами – ни в C++, ни даже в TR1. Это объясняется тем, что такие массивы почти всегда можно заменить векторами или строками (vector и string). Если вы все-таки считаете, что было бы неплохо иметь auto_ptr и tr1::shared_ptr для массивов, обратите внимание на библиотеку Boost (см. правило 55). Там вы найдете классы boost::scoped_array и boost::shared_array, которые предоставляют нужное вам поведение.

Излагаемые здесь правила по использованию объектов для управления ресурсами предполагают, что если вы освобождаете ресурсы вручную (например, применяя delete помимо того, который содержится в деструкторе управляющего ресурсами класса), то поступаете неправильно. Готовые классы для управления ресурсами – вроде auto_ptr и tr1::shared_ptr – часто облегчают выполнение советов из настоящего правила, но иногда приходится иметь дело с ресурсами, для которых поведение этих классов неадекватно. В таких случаях вам придется разработать собственные классы управления ресурсами. Это не так уж трудно сделать, но нужно принять во внимание некоторые соображения (см. правила 14 и 15).

И в качестве завершающего комментария я должен сказать, что возврат из функции createInvestment обычного указателя – это путь к утечкам ресурсов, потому что после обращения к ней очень просто забыть вызвать delete для этого указателя. (Даже если используются auto_ptr или tr1::shared_ptr для выполнения delete, нужно не забыть «обернуть» возвращенное значение интеллектуальным указателем.) Чтобы решить эту проблему, нам придется изменить интерфейс createInvestment, и это станет темой правила 18.

Что следует помнить

• Чтобы предотвратить утечку ресурсов, используйте объекты RAII, которые захватывают ресурсы в своих конструкторах и освобождают в деструкторах.

• Два часто используемых класса RAII – это tr1::shared_ptr и auto_ptr. Обычно лучше остановить выбор на классе tr1::shared_ptr, потому что его поведение при копировании соответствует интуитивным ожиданиям. Что касается auto_ptr, то после копирования он уже не указывает ни на какой объект.

Данный текст является ознакомительным фрагментом.