优先选择make_shared，因其通过单次内存分配提升性能并增强异常安全；当需自定义删除器、管理数组或构造函数非公有时，则必须使用new配合shared_ptr。
C++智能指针，特别是
shared_ptr
的构造，在
make_shared
和直接使用
new
表达式之间做选择，这并非一个简单的优劣判断，而更多是基于具体场景的需求和考量。通常，我个人会倾向于
make_shared
，因为它在性能和异常安全方面提供了明显的优势。然而，在某些特定且重要的场景下，我们依然需要依赖
new
来配合
shared_ptr
的构造。
当我们谈论
shared_ptr
的构造时，核心问题其实是：是让
shared_ptr
自己去管理通过
new
分配的内存，还是通过
make_shared
一次性完成对象的构造和控制块的创建？
从我的经验来看，大多数时候，我都会倾向于
make_shared
。为什么呢？最直观的感受就是，它写起来更简洁，而且背后隐藏着一个非常重要的优化：单次内存分配。当我们写
new MyObject()
然后用
shared_ptr ptr(new MyObject());
时，实际上发生了两次内存分配：一次是为
MyObject
对象本身，另一次是为
shared_ptr
的控制块（里面包含引用计数、弱引用计数以及类型擦除的删除器等信息）。而
make_shared()
则聪明地将这两者合并成一次分配。这不仅仅是减少了一次系统调用开销，更重要的是，它能更好地利用缓存，减少内存碎片，在高性能场景下，这种差异是能感知到的。
不过，这也不是绝对的。比如，如果我的类构造函数是私有的，或者需要传递一个自定义的deleter（删除器），
make_shared
就显得力不从心了。这时候，我还是得老老实实地用
new
，然后将自定义deleter作为
shared_ptr
构造函数的第二个参数传进去。这就像是，
make_shared
提供了一个非常方便且高效的“套餐”，但如果你需要“定制服务”，就得自己动手了。
立即学习“C++免费学习笔记（深入）”；
make_shared
make_shared
为何能提供性能优势？探究其底层机制
make_shared
的核心优势在于其内存分配策略。当我们使用
shared_ptr p(new T(args));
时，C++运行时需要做两件事：
调用
new T(args)
来在堆上分配
T
类型的内存，并构造对象。
shared_ptr
的构造函数会在堆上再分配一块内存，用于存储控制块（control block）。这个控制块包含了引用计数、弱引用计数以及类型擦除的删除器等信息。这两次独立的内存分配，意味着两次系统调用，以及潜在的内存碎片问题。
而
make_shared(args)
则不同。它进行的是一次性内存分配。它会计算好
T
对象所需空间和控制块所需空间的总和，然后一次性从堆上申请这么大一块连续的内存。在这块内存中，它会首先构造
T
对象，紧接着就是控制块。这种“合二为一”的做法带来了几个显而易见的优势：
减少内存分配次数： 从两次变为一次，直接降低了系统调用的开销。提高缓存局部性： 对象和其控制块在内存中是相邻的，当访问对象时，控制块的数据很可能也已经被加载到CPU缓存中，从而提高访问效率。减少内存碎片： 连续的内存块管理起来更高效，减少了小块内存反复分配和释放造成的内存碎片化问题。
从我的角度来看，这就像是打包服务。你单独买个商品，再单独买个包装盒，需要两个交易。而
make_shared
就是直接给你一个已经包装好的商品，一次性搞定。对于频繁创建大量
shared_ptr
的场景，这种优化是实打实的。
什么时候应该优先选择
make_shared
make_shared
？实用场景分析
绝大多数情况下，
make_shared
都应该是你的首选，特别是当你满足以下条件时：
追求性能优化： 如果你的程序对性能敏感，需要频繁创建和销毁
shared_ptr
，
make_shared
的单次内存分配优势将非常明显。注重异常安全： 考虑这个表达式：
f(shared_ptr(new T()), shared_ptr(new U()));
。如果
new T()
成功，但
new U()
抛出异常，那么
new T()
分配的内存可能永远无法被
shared_ptr
接管并释放，导致内存泄漏。而
make_shared
则不会有这个问题，因为它在一次操作中完成了对象的创建和智能指针的绑定。例如，
f(make_shared(), make_shared());
，即使第二个
make_shared
失败，第一个
make_shared
创建的对象也会被正确管理。这是我个人非常看重的一点，毕竟代码的健壮性比什么都重要。对象构造函数是公开的：
make_shared
需要直接调用对象的构造函数。如果你的构造函数是私有的或保护的（例如，为了强制使用工厂方法），那么
make_shared
就无法直接使用。不需要自定义删除器：
make_shared
不支持直接指定自定义删除器。如果你需要为
shared_ptr
提供一个非默认的删除逻辑（例如，释放一个C风格的资源句柄，或者将对象归还到对象池），那么你必须使用
new
表达式来构造对象，然后将自定义删除器作为
shared_ptr
构造函数的第二个参数。
简而言之，如果你只是想创建一个普通的
shared_ptr
来管理一个堆上的对象，并且没有特殊的删除需求，
make_shared
就是那个“无脑选”的选项。
new
new
与
shared_ptr
结合使用的不可替代场景与考量
尽管
make_shared
有很多优点，但
new
表达式配合
shared_ptr
的构造方式，在某些特定场景下依然是不可或缺的。
自定义删除器（Custom Deleter）： 这是最常见也是最重要的一个理由。当你的对象需要非标准的释放逻辑时，比如管理文件句柄、数据库连接、或者需要返回到对象池而不是直接
delete
时，
make_shared
就无能为力了。你必须使用
new
来创建对象，然后将自定义删除器作为
shared_ptr
的第二个构造函数参数传入。
#include #include #include // For FILE*struct FileCloser { void operator()(FILE* f) const { if (f) { fclose(f); std::cout << "File closed." << std::endl; } }};// 使用new和自定义删除器std::shared_ptr file_ptr(fopen("test.txt", "w"), FileCloser{});// make_shared无法直接支持// std::make_shared(fopen("test.txt", "w"), FileCloser{}); // 编译错误
在我看来，这种场景下，
new
是唯一且正确的选择，它提供了
shared_ptr
的灵活性。
weak_ptr
的内存保留考量（特定情况）： 这是一个比较微妙的点。当一个
shared_ptr
的所有引用都消失了，但仍有
weak_ptr
指向它时，
make_shared
分配的内存会保留下来，直到最后一个
weak_ptr
也失效。这是因为
make_shared
将对象和控制块放在一起，如果提前释放对象，控制块就无法访问了。这意味着，即使对象已经逻辑上被销毁，其占用的内存可能仍然无法归还给系统，直到所有
weak_ptr
都过期。而使用
new
分配的对象，当
shared_ptr
的引用计数降到零时，对象内存会立即被释放。控制块的内存则会保留到
weak_ptr
计数为零。在某些内存极其敏感，且
weak_ptr
生命周期可能很长的情况下，这种差异可能值得考虑。不过，这通常是过度优化，除非你真的遇到了内存压力问题。
数组的
shared_ptr
管理： C++17之前，
shared_ptr
对数组的支持并不直接。虽然你可以通过
shared_ptr
来管理数组，但
make_shared
没有对应的
make_shared
版本。所以，如果你需要
shared_ptr
来管理一个动态分配的数组，你仍然需要使用
new[]
，并提供一个自定义删除器（或者依赖C++17后的
shared_ptr
自动处理）。
#include #include // C++11/14 管理数组std::shared_ptr arr_ptr_old(new int[10], [](int* p){ delete[] p; });// C++17及以后，可以这样（但make_shared(10) 仍不可用）std::shared_ptr arr_ptr_cxx17(new int[10]);
当然，对于数组，
std::vector
通常是更好的选择，但如果必须用
shared_ptr
管理原生数组，
new
是必经之路。
总的来说，
make_shared
是日常开发中的“默认选项”，它在性能和异常安全方面提供了显著的优势。但当你的需求超出了
make_shared
的范围，比如需要自定义删除行为，或者在极少数情况下需要精细控制内存生命周期时，
new
结合
shared_ptr
的传统方式依然是不可替代的。选择哪种方式，最终还是取决于对项目具体需求的深刻理解。
以上就是C++智能指针构造方式 make_shared和new选择的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1473641.html
微信扫一扫 
支付宝扫一扫 
