使用std::make_shared更高效，因它合并对象和控制块的内存分配为一次，减少开销并提升异常安全性；而用new构造需两次分配，性能更低且有泄漏风险。
直接使用
std::make_shared
通常更高效，因为它能减少一次内存分配。它将对象本身和 shared_ptr 的控制块（引用计数等信息）分配在同一块连续的内存中。
std::make_shared 通常是首选的 shared_ptr 构造方法，因为它具有性能优势和异常安全性。
为什么使用
new
new
构造
shared_ptr
会降低性能？
当你使用
new
分配对象，然后用这个指针构造
shared_ptr
时，实际上发生了两次内存分配。第一次是为对象本身分配内存，第二次是为
shared_ptr
的控制块分配内存。
std::make_shared
将这两者合并为一次分配，减少了内存分配的开销，也减少了内存碎片化的可能性。想象一下，你搬家，
std::make_shared
就像一次性打包所有东西，而
new
分配再构造就像先搬家具，再搬杂物，费时费力。
更具体地说，控制块包含了引用计数、weak count（用于
weak_ptr
）以及可能的自定义删除器。这些信息对于
shared_ptr
的正常工作至关重要。
std::make_shared
std::make_shared
如何提高异常安全性？
考虑以下代码：
process_widget(std::shared_ptr(new Widget), function_that_might_throw());
如果
new Widget
成功执行，但
function_that_might_throw()
抛出了异常，那么
new Widget
返回的指针将会泄漏，因为
shared_ptr
还没有构造成功。
使用
std::make_shared
可以避免这个问题：
process_widget(std::make_shared(), function_that_might_throw());
std::make_shared
在一次操作中完成对象的分配和
shared_ptr
的构造，要么全部成功，要么全部失败，从而保证了异常安全性。
std::make_shared
std::make_shared
有什么缺点吗？
虽然
std::make_shared
优点很多，但也有一些情况下不适合使用。
自定义删除器： 如果你需要使用自定义删除器，并且删除器的大小很大，那么将其存储在控制块中可能会造成额外的内存开销。在这种情况下，使用
new
分配对象，然后使用自定义删除器构造
shared_ptr
可能更合适。
内存占用： 当
weak_ptr
指向由
std::make_shared
创建的对象时，即使所有
shared_ptr
都被销毁，控制块仍然存在，直到所有
weak_ptr
也被销毁。这意味着对象占用的内存可能无法立即释放。不过，这通常不是一个严重的问题，除非内存资源非常有限。
不完全类型：
std::make_shared
需要在调用时知道模板参数的完整类型。如果你的类是不完全类型（例如，只有声明而没有定义），则不能使用
std::make_shared
。
总的来说，
std::make_shared
是一种优秀的
shared_ptr
构造方式，但在特定情况下需要权衡其优缺点。通常情况下，优先使用
std::make_shared
是一个好的习惯。
以上就是为什么应该优先使用std::make_shared而不是直接用new构造shared_ptr的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474351.html
微信扫一扫 
支付宝扫一扫 
