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

Функции std::make_uniqueи std::make_sharedпредставляют собой две из трех make -функций , т.e. функций, которые принимают произвольное количество аргументов, выполняют их прямую передачу конструктору объекта, создаваемого в динамической памяти, и возвращают интеллектуальный указатель на этот объект. Третья mаkе-функция — std::allocate_shared. Она работает почти так же, как и std::make_shared, за исключением того, что первым аргументом является объект распределителя, использующийся для выделения динамической памяти.

Даже самое тривиальное сравнение создания интеллектуального указателя с помощью mаkе-функции и без участия таковой показывает первую причину, по которой применение таких функций является предпочтительным. Рассмотрим следующий код.

auto upw1(std::make_unique< Widget>()); // С mаkе-функцией

std::unique_ptr< Widget> upw2(new Widget); // Без make-функции

auto spw1(std::make_shared< Widget>()); // С make-функцией

std::shared_ptr< Widget> spw2(new Widget); // Без make-функции

Я подчеркнул важное отличие: версия с применением оператора newповторяет созданный тип, в то время как mаkе-функции этого не делают. Повторение типа идет вразрез с основным принципом разработки программного обеспечения: избегать дублирования кода. Дублирование в исходном тексте увеличивает время компиляции, может вести к раздутому объектному коду и в общем случае приводит к коду, с которым сложно работать. Зачастую это ведет к несогласованному коду, а несогласованности в коде часто ведут к ошибкам. Кроме того, чтобы набрать на клавиатуре что-то дважды, надо затратить в два раза больше усилий, чем для единственного набора, а кто из нас не любит сократить эту работу?

Второй причиной для предпочтения mаkе-функций является безопасность исключений. Предположим, что у нас есть функция для обработки Widgetв соответствии с некоторым приоритетом:

void processWidget(std::shared_ptr spw, int priority);

Передача std::shared_ptrпо значению может выглядеть подозрительно, но в разделе 8.1 поясняется, что если processWidgetвсегда делает копию std::shared_ptr(например, сохраняя ее в структуре данных, отслеживающей обработанные объекты Widget), то это может быть разумным выбором.

Предположим теперь, что у нас есть функция для вычисления приоритета

int computePriority();

и мы используем ее в вызове processWidget, который использует оператор newвместо std::make_shared:

processWidget( // Потенциальная

std::shared_ptr(new Widget), // утечка

computePriority()); // ресурса

Как указывает комментарий, этот код может приводить к утечке Widget, вызванной применением new. Но почему? И вызывающий код, и вызываемая функция используют указатели std::shared_ptr, а std::shared_ptrспроектированы для предотвращения утечек ресурсов. Они автоматически уничтожают то, на что указывают, когда исчезает последний std::shared_ptr. Если все везде используют указатели std::shared_ptr, о какой утечке может идти речь?

Ответ связан с тем, как компиляторы транслируют исходный код в объектный. Во время выполнения аргументы функции должны быть вычислены до вызова функции, так что в вызове processWidgetдо того, как processWidgetначнет свою работу, должно произойти следующее.

• Выражение new Widgetдолжно быть вычислено, т.e. в динамической памяти должен быть создан объект Widget.

• Должен быть вызван конструктор std::shared_ptr, отвечающий за управление указателем, сгенерированным оператором new.

• Должна быть вызвана функция computePriority.

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

1. Выполнить new Widget.

2. Выполнить computePriority.

3. Вызвать конструктор std::shared_ptr.

Если сгенерирован такой код и во время выполнения computePriorityгенерирует исключение, созданный на первом шаге в динамической памяти Widgetбудет потерян, так как он не будет сохранен в указателе std::shared_ptr, который, как предполагается, начнет управлять им на третьем шаге.