но иногда приходится иметь дело с ресурсами, для которых поведение этих классов неадекватно. В таких случаях вам придется разработать собственные классы управления ресурсами. Это не так уж трудно сделать, но нужно принять во внимание некоторые соображения (см. правила 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 изложена идея
Например, предположим, что вы используете написанный на языке C интерфейс для работы с мьютексами – объектами типа Mutex, в котором есть функции lock и unlock:
void lock(Mutex *pm); // захватить мьютекс, на который указывает pm
void unlock(Mutex *pm); // освободить семафор
Чтобы гарантировать, что вы не забудете освободить ранее захваченный Mutex, можно создать управляющий класс. Базовая структура такого класса продиктована принципом RAII, согласно которому ресурс захватывается во время конструирования объекта и освобождается при его уничтожении:
class Lock {
public:
explicit Lock(Mutex *pm)
: mutexPtr(pm)
{lock(mutexPtr);} // захват ресурса
~Lock() {unlock(mutexPtr);} // освобождение ресурса
private:
Mutex *mutexPtr;
};
Клиенты используют класс Lock, как того требует идиома RAII:
Mutex m; // определить мьютекс, который вам нужно использовать
...
{ // создать блок для определения критической секции
Lock ml(&m); // захватить мьютекс
... // выполнить операции критической секции
} // автоматически освободить мьютекс в конце блока
Все прекрасно, но что случится, если скопировать объект Lock?
Lock ml1(&m); // захват m
Lock ml2(ml1); // копирование m1 в m2 – что должно произойти?
Это частный пример общего вопроса, с которым сталкивается каждый разработчик классов RAII: что должно происходить при копировании RAII-объекта? В большинстве случаев выбирается один из двух вариантов:
• Запрет копирования. Во многих случаях не имеет смысла разрешать копирование объектов RAII. Вероятно, это справедливо для класса вроде Lock, потому что редко нужно иметь копии примитивов синхронизации (каковым является мьютекс). Когда копирование RAII-объектов не имеет смысла, вы должны запретить его. Правило 6 объясняет, как это сделать: объявите копирующие операции закрытыми. Для класса Lock это может выглядеть так:
сlass Lock: private Uncopyable { // запрет копирования –
public: // см. правило 6
... // как раньше
};
• Подсчет ссылок на ресурс. Иногда желательно удерживать ресурс до тех пор, пока не будет уничтожен последний объект, который его использует. В этом случае при копировании RAII-объекта нужно увеличивать счетчик числа объектов, ссылающихся на ресурс. Так реализовано «копирование» в классе tr1::shared_ptr.
Часто RAII-классы реализуют копирование с подсчетом ссылок путем включения члена типа tr1::shared_ptr<Mutex>. К сожалению, поведение по умолчанию tr1::shared_ptr заключается в том, что он удаляет то, на что указывает, когда значение счетчика ссылок достигает нуля, а это не то, что нам нужно. Когда мы работаем с Mutex, нам нужно просто разблокировать его, а не выполнять delete.
К счастью, tr1::shared_ptr позволяет задать «чистильщика» – функцию или функциональный объект, который должен быть вызван, когда счетчик ссылок достигает нуля (эта функциональность не предусмотрена для auto_ptr, который
class Lock {
public:
explicit Lock(Mutex *pm) // инициализировать shared_ptr объектом
: mutexPtr(pm, unlock) // Mutex, на который он будет
// указывать, функцией unlock
{ // в качестве чистильщика
lock(mutexPtr.get());
}
private:
std::tr1::shared_ptr<Mutex> mutexPtr; // использовать
}; // shared_ptr вместо
// простого указателя
Отметим, что в этом примере в классе Lock больше нет деструктора. Просто в нем отпала необходимость. В правиле 5 объясняется, что деструктор класса (независимо от того, сгенерирован он компилятором или определен пользователем) автоматически вызывает деструкторы нестатических данных-членов класса. В нашем примере это mutexPtr. Но деструктор mutexPtr автоматически вызовет функцию-чистильщик tr1::shared_ptr (в данном случае unlock), когда счетчик ссылок на мьютекс достигнет нуля. (Пользователи, которые будут знакомиться с исходным текстом класса, вероятно, будут благодарны за комментарии, указывающие, что вы не забыли о деструкторе, а просто положились на поведение по умолчанию деструктора, сгенерированного компилятором.)
• Копирование управляемого ресурса. Иногда допустимо иметь столько копий ресурса, сколько вам нужно, и единственная причина использования класса, управляющего ресурсами, – гарантировать, что каждая копия ресурса будет освобождена по окончании работы с ней. В этом случае копирование управляющего ресурсом объекта означает также копирование самого ресурса, который в него
