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

Анализ эффективности функции std::make_sharedв равной мере применим и к std::allocate_shared, так что преимущество повышения производительности функции std::make_sharedраспространяется и на нее.

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

Например, ни одна из make-функций не позволяет указывать пользовательские удалители (см. разделы 4.1 и 4.2), в то время как конструкторы std::unique_ptrи std::shared_ptrэто позволяют. Для данного пользовательского удалителя Widget

auto widgetDeleter = [](Widget* pw) { … };

создание интеллектуального указателя с применением оператора newявляется очень простым:

std::unique_ptr

upw( new Widget, widgetDeleter);

std::shared_ptr spw( new Widget, widgetDeleter);

Сделать то же самое с помощью make-функции невозможно.

Второе ограничение на make-функции проистекает из синтаксических деталей их реализации. В разделе 3.1 поясняется, что при создании объекта, тип которого перегружает конструкторы как с параметрами std::initializer_list, так и без них, создание объекта с использованием фигурных скобок предпочитает конструктор s td::initializer_list, в то время как создание объекта с использованием круглых скобок вызывает конструктор, у которого нет параметров std::initializer_list. make-функции выполняют прямую передачу своих параметров конструктору объекта, но делается ли это с помощью круглых или фигурных скобок? Для некоторых типов ответ на этот вопрос очень важен. Например, в вызовах

auto upv = std::make_unique>(10, 20);

auto spv = std::make_shared>(10, 20);

результирующие интеллектуальные указатели должны указывать на векторы std::vectorс 10 элементами, значение каждого из которых — 20, или на векторы с двумя элементами, один со значением 10, а второй со значением 20? Или результат непредсказуем?

Хорошая новость в том, что результат все же предсказуем: оба вызова создают векторы std::vectorс 10 элементами, значение каждого из которых равно 20. Это означает что в mаkе-функциях прямая передача использует круглые, а не фигурные скобки. Плохая новость в том, что если вы хотите создавать свои указываемые объекты с помощью инициализаторов в фигурных скобках, то должны использовать оператор newнепосредственно. Использование mаkе-функции требует способности прямой передачи инициализатора в фигурных скобках, но, как поясняется в разделе 5.8, такие инициализаторы не могут быть переданы прямо. Однако в разделе 5.8 описывается и обходной путь: использование вывода типа autoдля создания объекта std::initializer_listиз инициализатора в фигурных скобках (см. раздел 1.2) с последующей передачей созданного объекта через mаkе-функцию:

// Создание std::initializer_list

auto initList = { 10, 20 };

// Создание std::vector с помощью конструктора

// с параметром std::initializer_list

auto spv = std::make_shared( initList);

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

Некоторые классы определяют собственные версии operator newи operator delete. Наличие этих функций подразумевает, что глобальные функции выделения и освобождения памяти для объектов этого типа являются неприемлемыми. Зачастую подпрограммы для конкретных классов разрабатываются только для выделения и освобождения блоков памяти, по размеру точно совпадающих с размером объектов класса; например, operator newи operator deleteдля класса Widgetзачатую способны выделять и освобождать только блоки памяти размером sizeof(Widget). Такие подпрограммы плохо подходят для поддержки пользовательского распределения памяти для указателей std::shared_ptr(с помощью std::allocate_shared) и их удаления (с помощью пользовательских удалителей), поскольку количество запрашиваемой std::allocate_sharedпамяти не совпадает с размером динамически создаваемого объекта (который равен размеру этого объекта плюс размер управляющего блока). Соответственно, применение mаkе-функций для создания объектов типов со специфичными для данного класса версиями operator newи operator deleteобычно является плохой идеей.

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

Как я уже отмечал, управляющий блок содержит, помимо самого счетчика ссылок, некоторую учетную информацию. Счетчик ссылок отслеживает, сколько указателей std::shared_ptrссылаются на управляющий блок, но управляющий блок содержит и второй счетчик ссылок, который подсчитывает, сколько указателей std::weak_ptrссылаются на этот управляющий блок. Этот второй счетчик ссылок известен как слабый счетчик (weak count) [14] На практике значение слабого счетчика не всегда совпадает с количеством указателей std::weak_ptr , ссылающихся на управляющий блок, поскольку разработчики библиотеки нашли способы добавлять в слабый счетчик дополнительную информацию, которая упрощает генерацию лучшего кода. В данном разделе мы игнорируем этот факт и считаем, что значение слабого счетчика представляет собой количество указателей std::weak_ptr , ссылающихся на управляющий блок.)). . Когда указатель std::weak_ptrпроверяет, не является ли он просроченным (см. раздел 4.2), он делает это путем обращения к счетчику ссылок (но не к слабому счетчику) в управляющем блоке, на который ссылается. Если счетчик ссылок равен нулю (т.e. если указываемый объект не имеет указателей std::shared_ptr, указывающих на него, и, таким образом, является удаленным), указатель std::weak_ptrявляется просроченным. В противном случае он просроченным не является.