Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

Управляющий блок обычно имеет размер в несколько слов, хотя пользовательские удалители и распределители памяти могут его увеличить. Обычная реализация управляющего блока оказывается более интеллектуальной, чем можно было бы ожидать. Она применяет наследование, и при этом даже имеются виртуальные функции. (Все это требуется для того, чтобы обеспечить корректное уничтожение указываемого объекта.) Это означает, что применение указателей std::shared_ptrберет на себя также стоимость механизма виртуальной функции, используемой управляющим блоком.

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

Они не являются наилучшим решением для любой задачи управления ресурсами. Но для предоставляемой ими функциональности цена std::shared_ptrвесьма разумна. В типичных условиях, когда использованы удалитель и распределитель памяти по умолчанию, а std::shared_ptrсоздается с помощью std::make_shared, размер управляющего блока составляет около трех слов, и его выделение, по сути, ничего не стоит. (Оно встроено в выделение памяти для указываемого им объекта. Дополнительная информация об этом приведена в разделе 4.4.) Разыменование std::shared_ptrне более дорогостояще, чем разыменование обычного указателя. Выполнение операций, требующих работы со счетчиком ссылок (например, копирующий конструктор или копирующее присваивание, удаление) влечет за собой одну или две атомарные операции, но эти операции обычно отображаются на отдельные машинные команды, так что, хотя они могут быть дороже неатомарных команд, они все равно остаются отдельными машинными командами. Механизм виртуальных функций в управляющем блоке обычно используется только однажды для каждого объекта, управляемого указателями std::shared_ptr: когда происходит уничтожение объекта.

В обмен на эти весьма скромные расходы вы получаете автоматическое управление временем жизни динамически выделяемых ресурсов. В большинстве случаев применение std::shared_ptrзначительно предпочтительнее, чем ручное управление временем жизни объекта с совместным владением. Если вы сомневаетесь, можете ли вы позволить себе использовать std::shared_ptr, подумайте, точно ли вам нужно обеспечить совместное владение. Если вам достаточно или даже может быть достаточно исключительного владения, лучшим выбором является std::unique_ptr. Его профиль производительности близок к таковому для обычных указателей, а “обновление” std::unique_ptrдо std::shared_ptrвыполняется очень легко, так как указатель std::shared_ptrможет быть создан из указателя std::unique_ptr.

Обратное неверно. После того как вы включили управление временем жизни ресурса с помощью std::shared_ptr, обратной дороги нет. Даже если счетчик ссылок равен единице, нельзя вернуть владение ресурсом для того, чтобы, скажем, им управлял std::unique_ptr. Контракт владения между ресурсом и указателями std::shared_ptr, которые указывают на ресурс, написан однозначно — “пока смерть не разлучит нас”. Никаких разводов и раздела имущества не предусмотрено.

Есть еще кое-что, с чем не могут справиться указатели std::shared_ptr, — массивы. Это еще одно их отличие от указателей std::unique_ptr. Класс std::shared_ptrимеет API, предназначенное только для работы с указателями на единственные объекты. Не существует std::shared_ptr. Время от времени “крутые” программисты натыкаются на мысль использовать std::shared_ptrдля указания на массив, определяя пользовательский удалитель для выполнения освобождения массива (т.e. delete[]). Это можно сделать и скомпилировать, но это ужасная идея. С одной стороны, класс std::shared_ptrне предоставляет оператор operator[], так что индексирование указываемого массива требует неудобных выражений с применением арифметики указателей. С другой стороны, std:: shared_ptrподдерживает преобразование указателей на производные классы в указатели на базовые классы, которое имеет смысл только для одиночных объектов, но при применении к массивам оказывается открытой дырой в системе типов. (По этой причине API std::unique_ptrзапрещает такие преобразования.) Что еще более важно, учитывая разнообразие альтернатив встроенным массивам в С++11 (например, std::array, std::vector, std::string), объявление интеллектуального указателя на тупой массив всегда является признаком плохого проектирования.