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



Любой интерфейс, который требует, чтобы пользователь что-то помнил, может быть использован неправильно, ибо пользователь вполне способен забыть, что от него требуется. Например, в правиле 13 представлена фабричная функция, которая возвращает указатель на динамически распределенный объект в иерархии Investment:


>Investment *createInvestment(); // из правила 13: параметры

>// для простоты опущены


Чтобы избежать утечки ресурсов, указатель, возвращенный createInvestment, обязательно должен быть удален. Следовательно, пользователь может совершить, по крайней мере, две ошибки: забыть удалить указатель либо удалить его более одного раза.

Правило 13 показывает, как клиенты могут поместить значение, возвращенное createInvestment, в «интеллектуальный» указатель наподобие auto_ptr или tr1::shared_ptr, возложив тем самым на него ответственность за вызов delete. Но что, если клиент забудет применить «интеллектуальный» указатель? Во многих случаях для предотвращения этой проблемы лучше было бы написать фабричную функцию, которая сама возвращает «интеллектуальный» указатель:


>std::tr1::shared_ptr createInvestment();


Тогда пользователь будет вынужден сохранять возвращаемое значение в объекте типа tr1::shared_ptr, и ему не придется помнить о том, что объект Investment по завершении работы с ним необходимо удалить.

Фактически возврат значения типа tr1::shared_ptr позволяет проектировщику интерфейса предотвратить и многие другие ошибки, связанные с освобождением ресурса, потому что, как объяснено в правиле 14, tr1::shared_ptr допускает привязку функции-чистильщика к интеллектуальному указателю при его создании (auto_ptr не имеет такой возможности).

Предположим, что от пользователя, который получил указатель Investment* от createInvestment, ожидается, что в конце работы он передаст его функции getRidOfInvestment, вместо того чтобы применить к нему delete. Подобный интерфейс – прямая дорога к другой ошибке, заключающейся в использовании не того механизма удаления ресурсов (пользователь может все-таки вызвать delete вместо getRidOfInvestment). Реализация createInvestment может снять эту проблему за счет того, что вернет tr1::shared_ptr с привязанной к нему в качестве чистильщика функцией getRidOfInvestment.

Конструктор tr1::shared_ptr принимает два аргумента: указатель, которым нужно управлять, и функцию-чистильщик, которая должна быть вызвана, когда счетчик ссылок достигнет нуля. Это наводит на мысль попытаться следующим образом создать нулевой указатель tr1::shared_ptr с getRidOfInvestment в качестве чистильщика: