C++中std::make_unique相比new的好处_C++14智能指针安全创建建议【最佳】

不该直接用 new 配合 std::unique_ptr 构造，因异常时会导致内存泄漏；应优先用 std::make_unique（原子操作、异常安全），仅在需自定义删除器或特殊数组初始化时才显式构造。

为什么不该直接用 new 配合 std::unique_ptr 构造？

直接写 std::unique_ptr(new T(args...)) 看似简洁，但存在异常安全漏洞：若 T 的构造函数抛异常（比如内存分配失败、初始化逻辑出错），new T(...) 已执行，但 std::unique_ptr 构造尚未开始，导致内存泄漏。

而 std::make_unique 是原子操作——它先分配内存、再就地构造对象、最后封装为 std::unique_ptr，三步要么全成功，要么在任何一步失败时自动清理已分配资源。

常见错误现象：std::unique_ptr(new MyClass(throw_on_construct())) 在构造抛异常后，MyClass 对象未被管理，new 返回的裸指针丢失，无法释放。

std::make_unique 不支持自定义删除器？

确实不支持。std::make_unique 只能生成使用默认删除器（delete）的 std::unique_ptr。如果你需要文件句柄、C API 资源或非 delete 释放逻辑，必须回退到显式构造：

立即学习“C++免费学习笔记（深入）”；

• 用 std::unique_ptr(new T, deleter)
• 或更安全的写法：std::unique_ptr(::operator new(sizeof(T)), deleter) + placement-new（但极少需手动这么干）

注意：自定义删除器场景下，std::make_unique 不是“不能用”，而是“根本没提供接口”——这不是缺陷，而是设计取舍：它专注解决最常见、最危险的裸 new 泄漏问题。

数组类型怎么用 std::make_unique？

C++14 起，std::make_unique 原生支持动态数组，但语法和语义与普通类型不同：

Face++旷视

Face⁺⁺ AI开放平台

下载

• std::make_unique(10) → 创建长度为 10 的 int 数组，等价于 new int[10]，析构时调用 delete[]
• std::make_unique(10) → 创建单个值为 10 的 int，不是数组
• 不支持带初始值列表的数组（如 std::make_unique({1,2,3})），这在 C++14/17 中非法；C++20 才通过 std::make_unique_for_overwrite 提供零初始化数组支持

误用后果：把 std::make_unique(n) 当作数组分配，会导致后续越界访问且析构错误（delete vs delete[] 不匹配）。

性能差异和编译器优化影响

理论上 std::make_unique 多一层函数调用，但现代编译器（GCC 7+、Clang 5+、MSVC 2017+）在 O2/O3 下会完全内联，生成的汇编与手写 new + 构造几乎一致。

真正影响性能的是隐式转换和模板实例化开销——尤其在头文件中高频使用时，可能略微增加编译时间。但这远小于运行时泄漏风险带来的代价。

容易忽略的一点：当 T 构造函数是 explicit 且接受单参数时，std::make_unique(arg) 仍能正常工作，而某些手写表达式（如 {arg} 初始化）可能因隐式转换限制报错。

复杂点在于：如果 T 的构造函数有重载或模板推导歧义（比如同时接受 int 和 std::string_view），std::make_unique 同样会遇到编译失败，这时必须显式指定类型或改用 static_cast 辅助。