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

Майерс Скотт
Шрифт:

Часто RAII-классы реализуют копирование с подсчетом ссылок путем включения члена типа tr1::shared_ptr<Mutex>. К сожалению, поведение по умолчанию tr1::shared_ptr заключается в том, что он удаляет то, на что указывает, когда значение счетчика ссылок достигает нуля, а это не то, что нам нужно. Когда мы работаем с Mutex, нам нужно просто разблокировать его, а не выполнять delete.

К счастью, tr1::shared_ptr позволяет задать «чистильщика» – функцию или функциональный объект, который должен быть вызван, когда счетчик ссылок достигает нуля (эта функциональность не предусмотрена для auto_ptr, который всегда удаляет указатель). Функция-чистильщик – это необязательный второй параметр конструктора tr1::shared_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), когда счетчик ссылок на мьютекс достигнет нуля. (Пользователи, которые будут знакомиться с исходным текстом класса, вероятно, будут благодарны за комментарии, указывающие, что вы не забыли о деструкторе, а просто положились на поведение по умолчанию деструктора, сгенерированного компилятором.)

• Копирование управляемого ресурса. Иногда допустимо иметь столько копий ресурса, сколько вам нужно, и единственная причина использования класса, управляющего ресурсами, – гарантировать, что каждая копия ресурса будет освобождена по окончании работы с ней. В этом случае копирование управляющего ресурсом объекта означает также копирование самого ресурса, который в него «обернут». То есть копирование управляющего ресурсом объекта выполняет «глубокое копирование». Некоторые реализации стандартного класса string включают указатели на память из «кучи», где хранятся символы, входящие в строку. Объект такого класса содержит указатель на память из «кучи». Когда объект string копируется, то копируется и указатель, и память, на которую он указывает. Здесь мы снова встречаемся с «глубоким копированием».

• Передача владения управляемым ресурсом. Иногда нужно гарантировать, что только один RAII-объект ссылается на ресурс, и при копировании такого объекта RAII владение ресурсом передается объекту-копии. Как объясняется в правиле 13, это означает копирование с применением auto_ptr.

Копирующие функции (конструктор копирования и оператор присваивания) могут быть сгенерированы компилятором, но если сгенерированные версии не делают того, что вам нужно (правило 5 объясняет поведение по умолчанию), придется написать их самостоятельно. Иногда имеет смысл поддерживать обобщенные версии этих функций. Такой подход описан в правиле 45.

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

• Копирование RAII-объектов влечет за собой копирование ресурсов, которыми они управляют, поэтому поведение ресурса при копировании определяет поведение RAII-объекта.

• Обычно при реализации RAII-классов применяется одна из двух схем: запрет копирования или подсчет ссылок, но возможны и другие варианты.

Правило 15: Предоставляйте доступ к самим ресурсам из управляющих ими классов

Управляющие ресурсами классы заслуживают всяческих похвал. Это бастион, защищающий от утечек ресурсов, а отсутствие таких утечек – фундаментальное свойство хорошо спроектированных систем. В идеальном мире вы можете положиться на эти классы для любых взаимодействий с ресурсами, не утруждая себя доступом к ним напрямую. Но мир неидеален. Многие программные интерфейсы требуют доступа к ресурсам без посредников. Если вы не планируете отказаться от использования таких интерфейсов (что редко имеет смысл на практике), то должны как-то обойти управляющий объект и работать с самим ресурсом.

Например, в правиле 13 изложена идея применения интеллектуальных указателей вроде auto_ptr или tr1::shared_ptr для хранения результата вызова фабричной функции createInvestment:

std::tr1::shared_ptr<Investment> pInv(createInvestment); // `ec "id`a^a`e"e`a 13

Предположим, есть функция, которую вы хотите применить при работе с объектами класса Investment:

int daysHeld(const Investment *pi); // возвращает количество дней