从我所做的研究中，听起来std::make_shared是构建std::shared_ptr的首选方法。具体是因为：
- 它只执行一个内存分配，而使用
new则至少执行两个。 - 如果 ctor 传递给 make_shared 投掷，那么它不会泄漏，就像新的一样。
我的问题是，假设我想要一个shared_ptr，我应该总是使用 make_shared ，还是在某些情况下首选new？
由于计数器和对象共享相同的分配，因此它们也共享相同的释放。
计数器必须持续到最后一shared_ptr，weak_ptr消失。 如果您有一个具有持久 weak_ptr 的大型对象(或许多小对象(，则在通过 make_shared 分配shared_ptr 时，这可能会导致内存争用。
其次，如果你有一个第三方 API，它为你提供指针或资源句柄，并且可能有自己的处置功能，那么make_shared既不适合也不可能在每种情况下使用。 创建自己的make_函数可以避免混乱的细节，让您处理此问题，并处理异常极端情况。
最后，虽然共享指针很棒，但它们也过于强大。 很多时候，我想要一个unique_ptr甚至一个boost::scoped_ptr，或者一个侵入性的引用计数指针，或者类似的东西来表示所有权。 只有当情况实际涉及资源的共享所有权时，才应使用shared_ptr：随意使用它，因为它"容易"，最终往往会得到相当于意大利面条代码的资源。
您可能必须处理返回动态分配对象的遗留代码。在这种情况下，您需要将 std::shared_ptr<T> ctor 与指针参数一起使用。它并不比使用std::make_shared可取，但它确实允许您在遗留代码中使用所有std::shared_ptr<T>优点。
我知道这并不严格等同于直接将 std::shared_ptr<T> ctor 与 new一起使用，但它是无法使用make_shared的std::shared_ptr<T>的有效用例。
我对你的问题的解释有点不确定。我假设使用shared_ptr<T>是合理的;我只能支持Yakk，为什么你一开始就不想使用shared_ptr。
有一种情况是不能使用 make_shared 或 allocate_shared 来构造shared_ptr，但需要使用相应的 ctor：如果需要传入自定义删除器，请参阅 shared_ptr 的 ctor 中的 (3( 和 (4(。
我在具有私有构造函数(来自静态工厂方法(的类上使用make_shared时遇到了问题。我认为没有一个简单的解决方案。
我应该一直使用make_shared，还是有新的 首选
当我们将裸指针存储在其他人分配的shared_ptr中时，不允许make_shared。 它只能调用public构造函数。但是，某些编译器中有一些关于使用此类make_shared访问受保护构造函数的报告。