Зачем использовать std :: make_unique в C ++ 17?

Насколько я понимаю, C ++ 14 был введен, std::make_uniqueпотому что из-за того, что порядок оценки параметров не был указан, это было небезопасно:

f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A

(Объяснение: если оценка сначала выделяет память для необработанного указателя, затем вызывает g()и исключение перед std::unique_ptrпостроением, тогда происходит утечка памяти.)

Вызов std::make_uniqueбыл способом ограничить порядок вызовов, что сделало вещи безопасными:

f(std::make_unique<MyClass>(param), g());             // Syntax B

С тех пор C ++ 17 уточнил порядок оценки, сделав синтаксис A безопасным, поэтому вот мой вопрос: есть ли еще причина использовать конструктор std::make_uniqueover std::unique_ptrв C ++ 17? Вы можете привести несколько примеров?

На данный момент я могу себе представить только одну причину, по которой он позволяет печатать MyClassтолько один раз (при условии, что вам не нужно полагаться на полиморфизм std::unique_ptr<Base>(new Derived(param))). Однако это кажется довольно слабой причиной, особенно когда std::make_uniqueне позволяет указать удалитель, в то время как std::unique_ptrэто делает конструктор.

И, чтобы прояснить, я не выступаю за удаление std::make_uniqueиз стандартной библиотеки (сохранение этого имеет смысл, по крайней мере, для обратной совместимости), а скорее задаюсь вопросом, есть ли еще ситуации, в которых настоятельно рекомендуетсяstd::unique_ptr

Вы правы, что главную причину убрали. По-прежнему существуют правила не использовать новые правила и меньше причин для набора текста (не нужно повторять тип или использовать слово new). По общему признанию, это не сильные аргументы, но мне очень нравится не видеть их newв своем коде.

Также не забывайте о последовательности. Вам обязательно нужно использовать, make_sharedчтобы использование было make_uniqueестественным и соответствовало рисунку. Это тот тривиальным изменение std::make_unique<MyClass>(param)к std::make_shared<MyClass>(param)(или наоборот) , где синтаксис требует гораздо больше перезаписи.

make_uniqueотличает Tот T[]и T[N], unique_ptr(new ...)не делает.

Вы можете легко получить неопределенное поведение, передав указатель, который был new[]изменен в unique_ptr<T>, или передав указатель, который был newизменен в unique_ptr<T[]>.

Причина в том, чтобы код был короче, без дубликатов. Сравнить

f(std::unique_ptr<MyClass>(new MyClass(param)), g());
f(std::make_unique<MyClass>(param), g());

Вы экономите MyClass, newи фигурные скобки. Стоимость make всего на один символ больше, чем у ptr .

Каждое использование newдолжно быть тщательно проверено на соответствие сроку службы; это удаляется? Только однажды?

Каждое использование make_uniqueне для этих дополнительных характеристик; пока объект-владелец имеет «правильное» время жизни, он рекурсивно делает уникальный указатель «правильным».

Это правда, что unique_ptr<Foo>(new Foo())во всех отношениях ¹ к make_unique<Foo>(); для этого просто требуется более простая команда «grep your source code for all use of newto audit it ».

^{1 на} самом деле ложь в общем случае. Идеальная пересылка не идеальна, {}инициализация по умолчанию, все массивы - исключения.

С тех пор C ++ 17 уточнил порядок оценки, сделав синтаксис A безопасным.

Этого действительно недостаточно. Полагаться на недавно введенный технический раздел как на гарантию безопасности - не очень надежная практика:

• Кто-то может скомпилировать этот код на C ++ 14.
• Вы могли бы поощрять использование raw в newдругом месте, например, путем копирования вашего примера.
• Как предполагает SM, поскольку существует дублирование кода, один тип может быть изменен без изменения другого.
• Какой-то автоматический рефакторинг IDE может переместить это в newдругое место (хорошо, конечно, шансов на это мало).

Как правило, это хорошая идея, чтобы ваш код был подходящим / надежным / четко действительным, не прибегая к разделению на разные языки, поиску незначительных или неясных технических положений в стандарте.

(по сути, это тот же аргумент, который я привел здесь относительно порядка уничтожения кортежей.)

Рассмотрим функцию void (std :: unique_ptr (new A ()), std :: unique_ptr (new B ())) {...}

Предположим, что new A () завершился успешно, но new B () выдает исключение: вы перехватываете его, чтобы возобновить нормальное выполнение вашей программы. К сожалению, стандарт C ++ не требует, чтобы объект A был уничтожен, а его память освобождена: утечка памяти происходит незаметно, и ее невозможно очистить. Обернув A и B в std :: make_uniques, вы уверены, что утечки не произойдет:

void function (std :: make_unique (), std :: make_unique ()) {...} Дело в том, что std :: make_unique и std :: make_unique теперь являются временными объектами, а очистка временных объектов правильно указана в стандарт C ++: их деструкторы будут запущены, и память будет освобождена. Поэтому, если вы можете, всегда предпочитайте выделять объекты с помощью std :: make_unique и std :: make_shared.