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

• Инкремент и декремент счетчика ссылок должны быть атомарными, поскольку могут присутствовать одновременное чтение и запись в разных потоках. Например, std::shared_ptr, указывающий на ресурс в одном потоке, может выполнять свой деструктор (тем самым уменьшая количество ссылок на указываемый им ресурс), в то время как в другом потоке указатель std::shared_ptrна тот же объект может быть скопирован (а следовательно, увеличивает тот же счетчик ссылок). Атомарные операции обычно медленнее неатомарных, так что несмотря на то, что обычно счетчики ссылок имеют размер в одно слово, следует рассматривать их чтение и запись как относительно дорогостоящие операции.

Возбудил ли я ваше любопытство, когда написал, что конструкторы std::shared_ptr“обычно” увеличивают счетчик ссылок для указываемого объекта? При создании std::shared_ptr, указывающего на объект, всегда добавляется еще один интеллектуальный указатель std::shared_ptr, так почему же счетчик ссылок может увеличиваться не всегда ?

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

Подобно std::unique_ptr(см. раздел 4.1), std::shared_ptrв качестве механизма удаления ресурса по умолчанию использует delete, но поддерживает и пользовательские удалители. Однако дизайн этой поддержки отличается от дизайна для std::unique_ptr. Для std::unique_ptrтип удалителя является частью типа интеллектуального указателя. Для std::shared_ptrэто не так:

auto loggingDel = [](Widget *pw) // Пользовательский удалитель

{ // (как в разделе 4.1)

makeLogEntry(pw);

delete pw;

};

std::unique_ptr< // Тип удалителя является

Widget, decltype(loggingDel) // частью типа указателя

> upw(new Widget, loggingDel);

std::shared_ptr // Тип удалителя не является

spw(new Widget, loggingDel); // частью типа указателя

Дизайн std::shared_ptrболее гибок. Рассмотрим два указателя std::shared_ptr,каждый со своим пользовательским удалителем разных типов (например, из-за того, что пользовательские удалители определены с помощью лямбда-выражений):

auto customDeleter1 = [](Widget *pw) { … }; // Пользовательские

auto customDeleter2 = [](Widget *pw) { … }; // удалители

// разных типов

std::shared_ptr pw1(new Widget, customDeleter1);

std::shared_ptr pw2(new Widget, customDeleter2);

Поскольку pw1и pw2имеют один и тот же тип, они могут быть помещены в контейнер объектов этого типа:

std::vector> vpw( pw1, pw2 };

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

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

А он и не может. Ему приходится использовать дополнительную память, но эта память не является частью объекта std::shared_ptr. Она располагается в динамической памяти или, если создатель std::shared_ptrвоспользуется поддержкой со стороны std::shared_ptrпользовательских распределителей памяти, там, где выделит память такой распределитель. Ранее я отмечал, что объект std::shared_ptrсодержит указатель на счетчик ссылок для объекта, на который он указывает. Это так, но это немного не так, поскольку счетчик ссылок является частью большей структуры данных, известной под названием управляющий блок (control block). Управляющий блок имеется для каждого объекта, управляемого указателями std::shared_ptr. Управляющий блок в дополнение к счетчику ссылок содержит копию пользовательского удалителя, если таковой был указан. Если указан пользовательский распределитель памяти, управляющий блок содержит и его копию. Управляющий блок может также содержать дополнительные данные, включающие, как поясняется в разделе 4.4, вторичный счетчик ссылок, известный как слабый счетчик, но в данном разделе мы его игнорируем. Мы можем представить память, связанную с объектом std::shared_ptr, как имеющую следующий вид:

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

• Функция std::make_shared (см. раздел 4.4) всегда создает управляющий блок. Она производит новый объект, на который будет указывать интеллектуальный указатель, так что в момент вызова std::make_sharedуправляющий блок для этого объекта, определенно, не существует.

• Управляющий блок создается тогда, когда указатель std::shared_ptr создается из указателя с исключительным владением (т.e. std::unique_ptr или std::auto_ptr ). Указатели с исключительным владением не используют управляющие блоки, так что никакого управляющего блока для указываемого объекта не существует. (Как часть своего построения std::shared_ptrосуществляет владение указываемым объектом, так что указатель с исключительным владением становится нулевым.)

• Когда конструктор std::shared_ptr вызывается с обычным указателем, он создает управляющий блок. Если вы хотите создать std::shared_ptrиз объекта, у которого уже имеется управляющий блок, вы предположительно передаете в качестве аргумента конструктора std::shared_ptrили std::weak_ptr(см. раздел 4.3), а не обычный указатель. Конструкторы std::shared_ptr, принимающие в качестве аргументов указатели std::shared_ptrили std::weak_ptr, не создают новые управляющие блоки, поскольку могут воспользоваться управляющими блоками, на которые указывают переданные им интеллектуальные указатели.