std::make_unique＜T＞和std::make_shared＜T＞

更建议使用：std::make_unique<T>构造unique_ptr对象；std::make_shared<T>构造shared_ptr对象

 

std::make_shared是C++11的一部分，std::make_unique不是，它在C++14才纳入标准库。如果你使用的是C++11，不用忧伤，因为std::make_unique的简单版本很容易写出来：

1. template<typename T, typename... Ts>

2. std::unique_ptr<T> make_unique(Ts&&... params)

3. {

4. return std::unique_ptr<T>(new T(std::forward<Ts>(params)...));

5. }

make_unique只是把参数完美转发给要创建对象的构造函数，再从new出来的原生指针构造std::unique_ptr。这种形式的函数不支持数组和自定义删除器。

三个make函数：std::make_unique、std::make_shared、std::allocate_shared，make函数：把任意集合的参数完美转发给动态分配对象的构造函数，然后返回一个指向那对象的智能指针。std::allocate_shared，它与std::make_shared类似，除了它第一个参数是个分配器，指定动态分配对象的方式。

使用make函数更可取的第一个原因。考虑以下：

1. auto upw1(std::make_unique<Widget>()); // 使用make函数

2. std::unique_ptr<Widget> upw2(new Widget); // 不使用make函数

3. auto spw1(std::make_shared<Widget>()); // 使用make函数

4. std::shared_ptr<Widget> spw2(new Widget); // 不使用make函数

它们本质上的不同是：使用new的版本重复着需要创建的类型（即出现了两次Widget），而使用make函数不需要。

第二个原因异常安全。

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

计算优先级的函数，

int computePriority();

processWidget(std::shared_ptr<Widget>(new Widget), computePriority()); // 可能会资源泄漏

这代码中new出来的Widget可能会泄漏，为什么？

调用processWidget时，下面的事会在processWidget开始前执行：

• “new Widget”。
• std::shared_ptr构造函数执行。
• computePriority运行。

编译器在生成代码时不会保证上面的执行顺序，“new Widget”一定会在std::shared_ptr构造函数之前执行，但是computePriority可能在它们之前就被调用了，可能在它们之后，可能在它们之间。所以，编译器生成代码的执行顺序有可能是这样的：

1. 执行“new Widget”。
2. 执行computePriority。
3. 执行std::shared_ptr的构造函数。

如果生成的代码真的是这样，那么在运行时，computePriority产生了异常，步骤1中动态分配的Widget就泄漏了

使用std::make_shared可以避免这问题。

processWidget(std::make_shared<Widget>(), computePriority())

std::make_shared的一个特点（相比于直接使用new）是提高效率。使用std::make_shared允许编译器生成更小、更快的代码。考虑当我们直接使用new时：

std::shared_ptr<Widget> spw(new Widget);

很明显这代码涉及一次内存分配，不过，它实际上分配两次。每个std::shared_ptr内都含有一个指向控制块的指针，这控制块的内存是由std::shared_ptr的构造函数分配的，那么直接使用new，需要为Widget分配一次内存，还需要为控制块分配一次内存。

如果用std::make_shared呢，

auto spw = std::make_shared<Widget>();

一次分配就够了，因为std::make_shared会分配一大块内存来同时持有Widget对象和控制块。这种优化减少了程序的静态尺寸，因为代码只需要调用一次内存分配函数，增加了代码执行的速度，因为只需要分配一次内存。而且，使用std::make_shared能避免一些控制块的信息，潜在地减少了程序占用的内存空间。

但std::unique_ptr和std::shared_ptr可以指定删除器，make函数不可以，

auto widgetDeleter = [](Widget* pw) {...}

我们可以直接使用new创建智能指针：

1. std::unique_ptr<Widget, decltype(widgetDeleter)> upw(new Widget, widgetDeleter);

2. std::shared_ptr<Widget> spw(new Widget, widgetDeleter);

make函数的第二个限制。当创建一个对象时，如果该对象的重载构造函数带有std::initializer_list参数，那么使用大括号创建对象会偏向于使用带std::initializer_list构造，要使用圆括号创建对象才能使用到非std::initializer_list构造。make函数把它们的参数完美转发给对象的构造函数，那么它们用的是大括号还是圆括号呢？

1. auto upv = std::make_unique<std::vector<int>>(10, 20);

2. auto spv = std::make_shared<std::vector<int>>(10, 20);

上面两个都创建内含10个值为20的std::vector。make函数内，完美转发使用的是圆括号，而不是大括号。坏消息是如果你想用大括号初始化来构造指向的对象，你只能直接使用new，如果你想使用make函数，就要求完美转发的能力支持大括号初始化，但是大括号初始化不能被完美转发。不过也有一种能工作的方法：用auto推断大括号，从而创建一个std::initializer_list对象，然后把auto变量传递给make函数：

1. // 创建 std::initializer_list

2. auto initList = {10, 20};

3.  

4. // 使用std::initializer_list构造函数创建std::vector，容器中只有两个元素

5. auto spv = std::make_shared<std::vector<int>>(initList);

对于std::unique_ptr，只有两种情况（自定义删除器和大括号初始化）会让它的make函数出问题。对于std::shared_ptr和它的make函数，就多两种情况，这两种情况都是边缘情况，不过一些开发者就喜欢住在边缘。

一些类定义了自己的operator new和operator delete函数，这些函数的出现暗示着常规的全局内存分配和回收不适合这种类型的对象。通常情况下，设计这些函数只有为了精确分配和销毁对象。这两个函数不适合std::shared_ptr的自定义分配（借助std::allocate_shared）和回收（借助自定义删除器），因为std::allocate_shared请求内存的大小不是对象的尺寸，而是对象尺寸加上控制块尺寸。结果就是，使用make函数为那些定义自己版本的operator new和operator delete的类创建对象是糟糕的。

比起直接使用new，std::make_shared的占用内存大小和速度优势来源于：std::shared_ptr的控制块与它管理的对象放在同一块内存。当引用计数为0时，对象被销毁（即调用了析构函数），但是，它使用的内存不会释放，除非控制块也被销毁，因为对象和控制块在同一块动态分配的内存上。

控制块上除了引用计数还有别的信息。引用计数记录的是有多少std::shared_ptr指向控制块，但是控制块还有第二种引用计数，记录有多少std::weak_ptr指向控制块。这种引用计数称为weak count。当std::weak_ptr检查它是否过期时（expired），它通过检查控制块中的引用计数（不是weak count）来实现。如果引用计数为0，std::weak_ptr就过期，否则就没有过期。

但是，只要有std::weak_ptr指向控制块（weak count大于0），控制块就必须继续存在，而只要控制块存在，容纳它的内存块也依旧存在。那么，通过make函数创建对象分配的内存，要直到最后一个指向它的std::shared_ptr和std::weak_ptr对象销毁，才能被回收。

如果对象的类型非常大，并且最后一个std::shared_ptr销毁和最后一个std::weak_ptr销毁之间的时间间隔很大，那么对象销毁和内存被回收之间的会有延迟

如果直接使用new，ReallyBigType对象的内存只要最后一个std::shared_ptr被销毁就能被释放。

有个小小的性能问题，在异常不安全的调用中，我们传给processWidget的是一个右值

1. processWidget(

2. std::shared_ptr<Widget>(new Widget, cusDel), // 参数是右值

3. computePriority()

4. );

但是在异常安全的调用中，我们传递的是个左值：

processWidget(spw, computePriority());   // 参数是左值

因为processWidget的std::shared_ptr参数是值传递，从一个右值构造使用的是移动，从一个左值构造使用的是拷贝。对于std::shared_ptr，这差别挺大的，因为拷贝一个std::shared_ptr需要增加它的引用计数，而移动操作完全不用操作引用计数。

使用std::move来把spw转化为右值：

processWidget(std::move(spw), computePriority());  // 现在也一样高效

这是有趣的而且值得知道，但是通常也是不相干的，因为你很少有理由不用make函数，除非你有迫不得已的理由，否则，你应该使用make函数。

总结

需要记住的3点：

• 相比于直接使用new，make函数可以消除代码重复，提高异常安全，而且std::make_shared和std::allocate_shared生成的代码更小更快。
• 不适合使用make函数的场合包括需要指定自定义删除器和想要传递大括号初始值。
• 对于std::shared_ptr，使用make函数可能是不明智的场合包括（1）自定义内存管理函数的类、（2）内存紧张的系统中，有非常大的对象，然后std::weak_ptr比std::shared_ptr长寿。