Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ

...

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

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

std::tr1::shared_ptr // теперь оба объекта 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 // плохая идея! Будет

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

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

std::tr1::shared_ptr 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, то после копирования он уже не указывает ни на какой объект.

Правило 14: Тщательно продумывайте поведение при копировании классов, управляющих ресурсами

В правиле 13 изложена идея Получение Ресурса Есть Инициализация (Resource Acquisition Is Initialization – RAII), лежащая в основе создания управляющих ресурсами классов. Было также показано, как эта идея воплощается в классах auto_ptr и tr1::shared_ptr для управления динамически выделяемой из кучи памятью. Но не все ресурсы имеют дело с «кучей», и для них интеллектуальные указатели вроде auto_ptr и tr1::shared_ptr обычно не подходят. Время от времени вы будете сталкиваться со случаями, когда понадобится создать собственный класс для управления ресурсами.

Например, предположим, что вы используете написанный на языке C интерфейс для работы с мьютексами – объектами типа Mutex, в котором есть функции lock и unlock: