c++的std::make_shared相比直接new有何优势？ (避免内存泄漏)

std::make_shared 能减少内存泄漏风险，因为它将对象和控制块的分配合并为一次原子操作，异常时二者同时释放；而直接 new 配合 shared_ptr 构造函数是两次独立分配，中间异常会导致已分配对象无法接管而泄漏。

std::make_shared 为什么能减少内存泄漏风险

直接用 new 配合 std::s

hared_ptr 构造函数（如 std::shared_ptr(new T)）时，若构造过程中抛出异常，new 分配的内存可能无法被 shared_ptr 接管，导致泄漏。而 std::make_shared 把对象构造和控制块（control block）分配合并为一次堆分配，且保证二者原子性：要么全部成功，要么都不发生——异常安全得到保障。

内存布局差异直接影响异常安全性

std::make_shared 在同一块连续内存中同时存放控制块和对象，而手动 new 是两次独立分配：一次给对象，一次给控制块。这意味着：

• 手动方式中，若 new T() 成功但控制块分配失败（例如内存不足），已分配的 T 无法自动释放
• std::make_shared 即使在 T 的构造函数抛异常，控制块和对象的内存也由内部统一管理，不会泄漏
• 这种布局还带来缓存友好性提升，但主要优势仍是异常安全

哪些场景下 std::make_shared 不能替代 new

不是所有情况都能用 std::make_shared 替代 new：

• 类定义了 private 或 deleted 的构造函数，且未将 std::make_shared 声明为友元（C++17 起部分编译器放宽，但仍非标准保证）
• 需要自定义删除器（deleter）且该删除器不能通过默认参数传递（std::make_shared 不接受自定义 deleter）
• 需要构造非默认可构造类型，且参数是右值引用或涉及完美转发边界（某些老旧编译器对参数展开支持不完整）
• 继承体系中需调用派生类特定构造逻辑，而基类无合适构造签名匹配

auto ptr1 = std::make_shared("hello"); // 安全：一次分配，异常安全
auto ptr2 = std::shared_ptr(new std::string("hello")); // 危险：两步分配，中间可能异常

性能与兼容性要注意的细节

std::make_shared 的单次分配虽快，但注意：

• 它会为控制块预留额外空间（通常 16–32 字节），即使对象很小，也会占用至少一页内存；对大量小对象（如 int）可能浪费空间
• 在 C++11 中，std::make_shared 对参数是完美转发，但某些编译器对初始化列表（{...}）支持不一致，建议显式构造临时对象再传入
• 若对象类型重载了 operator new，std::make_shared 不会调用它——它始终使用全局 ::operator new 分配控制块+对象内存

真正容易被忽略的是：即使你没显式写 new，只要用了 std::shared_ptr(new T(...)) 这种形式，就仍处于异常泄漏风险区。是否安全，不取决于有没有裸指针变量，而取决于分配与所有权绑定是否原子。