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

retVal = ...; // retVal должен указывать

// на корректный объект

return retVal;

}

Конечно, если указатель, которым должен управлять pInv, можно было бы определить до создания pInv, то лучше было бы передать его конструктору pInv вместо инициализации pInv нулем с последующим присваиванием значения (см. правило 26).

Особенно симпатичное свойство tr1::shared_ptr заключается в том, что он автоматически использует определенного пользователем чистильщика, чтобы избежать другой потенциальной ошибки пользователя – «проблемы нескольких DLL». Она возникает, если объект создается оператором new в одной динамически скомпонованной библиотеке (DLL), а удаляется оператором delete в другой. На многих платформах в такой ситуации возникает ошибка во время исполнения. tr1::shared_ptr решает эту проблемы, поскольку его чистильщик по умолчанию использует delete из той же самой DLL, где был создан tr1::shared_ptr. Это значит, например, что если класс Stock является производным от Investment и функция createInvestment реализована следующим образом:

std::tr1::shared_ptr createInvestment()

{

return std::tr1::shared_ptr(new Stock);

}

то возвращенный ей объект tr1::shared_ptr можно передавать между разными DLL без риска столкнуться с описанной выше проблемой. Объект tr1::shared_ptr, указывающий на Stock, «помнит», из какой DLL должен быть вызван delete, когда счетчик ссылок на Stock достигнет нуля.

Впрочем, этот правило не о tr1::shared_ptr, а о том, как делать интерфейсы легкими для правильного использования и трудными – для неправильного. Но класс tr1::shared_ptr дает настолько простой способ избежать некоторых клиентских ошибок, что на нем стоило остановиться. Наиболее распространенная реализация tr1::shared_ptr находится в библиотеке Boost (см. правило 55). Размер объекта shared_ptr из Boost вдвое больше размера обычного указателя, в нем динамически выделяется память для служебных целей и данных, относящихся к чистильщику, используется вызов виртуальной функции для обращения к чистильщику, производится синхронизация потоков при изменении значения счетчика ссылок в многопоточной среде. (Вы можете отключить поддержку многопоточности, определив символ препроцессора.) Короче говоря, этот интеллектуальный указатель по размеру больше обычного, работает медленнее и использует дополнительную динамически выделяемую память. Но во многих приложениях эти дополнительные затраты времени исполнения будут незаметны, зато уменьшение числа ошибок пользователей заметят все.

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

• Хорошие интерфейсы легко использовать правильно и трудно использовать неправильно. Вы должны стремиться обеспечить эти характеристики в ваших интерфейсах.

• Для обеспечения корректного использования интерфейсы должны быть согласованы и совместимы со встроенными типами.

• Для предотвращения ошибок применяют следующие способы: создание новых типов, ограничение допустимых операций над этими типами, ограничение допустимых значений, а также освобождение пользователя от обязанностей по управлению ресурсами.

• Класс tr1::shared_ptr поддерживает пользовательские функции-чистильщики. Это снимает «проблему нескольких DLL» и может быть, в частности, использовано для автоматического освобождения мьютекса (см. правило 14).

Правило 19: Рассматривайте проектирование класса как проектирование типа

В C++, как и в других объектно-ориентированных языках программирования, при определении нового класса определяется новый тип. Потому большую часть времени вы как разработчик C++ будете тратить на совершенствование вашей системы типов. Это значит, что вы – не просто разработчик классов, но еще и разработчик типов. Перегруженные функции и операторы, управление распределением и освобождением памяти, определение инициализации и порядка уничтожения объектов – все это находится в ваших руках. Поэтому вы должны подходить к проектированию классов так, как разработчики языка подходят к проектированию встроенных типов.

Проектирование хороших классов – ответственная работа, и этим все сказано. Хорошие типы имеют естественный синтаксис, интуитивно воспринимаемую семантику и одну или более эффективных реализаций. В C++ плохо спланированное определение класса может сделать невозможным достижение любой из этих целей. Даже характеристики производительности функций-членов класса могут зависеть от того, как они объявлены.

Итак, как же проектировать эффективные классы? Прежде всего вы должны понимать, с чем имеете дело. Проектирование почти любого класса ставит перед разработчиком вопросы, ответы на которые часто ограничивают спектр возможных решений: