Why use std::make_unique in C++17?

Question

As far as I understand, C++14 introduced std::make_unique because, as a result of the parameter evaluation order not being specified, this was unsafe:

Answer 1

Consider void function(std::unique_ptr(new A()), std::unique_ptr(new B())) { ... }

Suppose that new A() succeeds, but new B() throws an exception: you catch it to resume the normal execution of your program. Unfortunately, the C++ standard does not require that object A gets destroyed and its memory deallocated: memory silently leaks and there's no way to clean it up. By wrapping A and B into std::make_uniques you are sure the leak will not occur:

void function(std::make_unique(), std::make_unique()) { ... } The point here is that std::make_unique and std::make_unique are now temporary objects, and cleanup of temporary objects is correctly specified in the C++ standard: their destructors will be triggered and the memory freed. So if you can, always prefer to allocate objects using std::make_unique and std::make_shared.

Answer 2

You're right that the main reason was removed. There are still the don't use new guidelines and that it is less typing reasons (don't have to repeat the type or use the word new). Admittedly those aren't strong arguments but I really like not seeing new in my code.

Also don't forget about consistency. You absolutely should be using make_shared so using make_unique is natural and fits the pattern. It's then trivial to change std::make_unique<MyClass>(param) to std::make_shared<MyClass>(param) (or the reverse) where the syntax A requires much more of a rewrite.

Answer 3

make_unique distinguishes T from T[] and T[N], unique_ptr(new ...) does not.

You can easily get undefined behaviour by passing a pointer that was new[]ed to a unique_ptr<T>, or by passing a pointer that was newed to a unique_ptr<T[]>.

Answer 4

The reason is to have shorter code without duplicates. Compare

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

You save MyClass, new and braces. It costs only one character more in make in comparison with ptr.

Answer 5

Every use of new has to be extra carefully audited for lifetime correctness; does it get deleted? Only once?

Every use of make_unique doesn't for those extra characteristics; so long as the owning object has "correct" lifetime, it recursively makes the unique pointer have "correct".

Now, it is true that unique_ptr<Foo>(new Foo()) is identical in all ways¹ to make_unique<Foo>(); it just requires a simpler "grep your source code for all uses of new to audit them".

---

¹ actually a lie in the general case. Perfect forwarding isn't perfect, {}, default init, arrays are all exceptions.

Answer 6

Since then, C++17 has clarified the evaluation order, making Syntax A safe too

That's really not good enough. Relying on a recently-introduced technical clause as the guarantee of safety is not a very robust practice:

• Someone might compile this code in C++14.
• You would be encouraging the use of raw new's elsewhere, e.g. by copy-pasting your example.
• As S.M. suggests, since there's code duplication, one type might get changed without the other one being changed.
• Some kind of automatic IDE refactoring might move that new elsewhere (ok, granted, not much chance of that).

Generally, it's a good idea for your code to be appropriate/robust/clearly valid without resorting to language-laywering, looking up minor or obscure technical clauses in the standard.

(this is essentially the same argument I made here about the order of tuple destruction.)