Навіщо використовувати 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[]відредагований до a unique_ptr<T>, або передавши вказівник, який був newвідредагований до a unique_ptr<T[]>.

Причиною є коротший код без дублікатів. Порівняйте

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

Ви економите MyClass, newі фігурні дужки. Це варто тільки один символ більше косметики в порівнянні з PTR .

Кожне використання newмає бути ретельно перевірено на предмет правильності використання протягом усього життя; це видаляється? Тільки один раз?

Кожне використання make_uniqueне для цих додаткових характеристик; поки об'єкт-власник має "правильний" час життя, він рекурсивно робить унікальний покажчик "правильним".

Тепер, це правда , що unique_ptr<Foo>(new Foo())ідентично у всіх відносинах ¹ до make_unique<Foo>(); для цього просто потрібен простіший "grep ваш вихідний код для будь-якого використання newдля їх аудиту".

¹ насправді брехня в загальному випадку. Ідеальне пересилання не є ідеальним, {}за замовчуванням init, масиви - це виключення.

З тих пір C ++ 17 уточнив порядок оцінки, зробивши Синтаксис A також безпечним

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

• Хтось може скомпілювати цей код у C ++ 14.
• Ви заохочуєте використовувати raw newв іншому місці, наприклад, шляхом копіювання вашого прикладу.
• Як припускає SM, оскільки існує дублювання коду, один тип може бути змінений без зміни іншого.
• Якийсь автоматичний рефакторинг IDE може перемістити це в newінше місце (гаразд, надано, мало шансів на це).

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

(це, по суті, той самий аргумент, який я тут наводив щодо порядку знищення кортежу.)

Розглянемо функцію void (std :: unique_ptr (new A ()), std :: unique_ptr (new B ())) {...}

Припустимо, що новий A () вдається, але новий 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.