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

Применение std::make_sharedпозволяет избежать таких проблем. Вызывающий код имеет следующий вид:

processWidget( std::make_shared(), // Потенциальной

computePriority()); // утечки ресурсов нет

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

Если мы заменим std::shared_ptrи std::make_sharedуказателем std::unique_ptrи функцией std::make_unique,все приведенные рассуждения останутся в силе. Использование std::make_uniqueвместо newтак же важно для написания безопасного с точки зрения исключений кода, как и применение std::make_shared.

Особенностью std::make_shared(по сравнению с непосредственным использованием new) является повышенная эффективность. Применение std::make_sharedпозволяет компиляторам генерировать меньший по размеру и более быстрый код, использующий более компактные структуры данных. Рассмотрим следующее непосредственное применение оператора new:

std::shared_ptr spw(new Widget);

Очевидно, что этот код предполагает выделение памяти, но фактически он выполняет два выделения. В разделе 4.2 поясняется, что каждый указатель std::shared_ptrуказывает на управляющий блок, содержащий, среди прочего, значение счетчика ссылок для указываемого объекта. Память для этого блока управления выделяется в конструкторе std::shared_ptr. Непосредственное применение оператора new, таким образом, требует одного выделения памяти для Widgetи второго — для управляющего блока.

Если вместо этого использовать std::make_shared,

auto spw = std::make_shared();

то окажется достаточно одного выделения памяти. Дело в том, что функция std::make_sharedвыделяет один блок памяти для хранения как объекта Widget, так и управляющего блока. Такая оптимизация снижает статический размер программы, поскольку код содержит только один вызов распределения памяти и повышает скорость работы выполнимого кода, так как выполняется только одно выделение памяти. Кроме того, применение std::make_sharedустраняет необходимость в некоторой учетной информации в управляющем блоке, потенциально уменьшая общий объем памяти, требующийся для программы.

Анализ эффективности функции 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-функции выполняют прямую передачу своих параметров конструктору объекта, но делается ли это с помощью круглых или фигурных скобок? Для некоторых типов ответ на этот вопрос очень важен. Например, в вызовах