在构造对象时是否有任何理由不使用std :: make_shared？

Question

我想不出任何情况

std::shared_ptr<Object> obj(new Object("foo", 1));

会优先考虑

auto obj = std::make_shared<Object>("foo", 1);

后者总是会产生更好的局部性并减少内存碎片。 是否有任何情况，您希望（或被迫）使用第一种形式，除了与返回原始指针的代码接口？

Answer 1

后者总是会产生更好的局部性并减少内存碎片。

不总是 。 鼓励实现对引用计数对象和引用计数使用单个分配，但不要求这样做。

为什么你不想使用std::make_shared ？ 考虑这样一种情况：你有一个你想要由std::shared_ptr拥有的大型动态分配对象，并且你知道对这个对象的弱引用可能比对象的强引用更长（可能有许多弱引用并且只有一两个短命的强引用）。

在这种情况下， std::make_shared将是一个糟糕的选择，假设它分配一个拥有对象和引用计数的块：分配的块（很大，记得）在没有强或弱之前不能被销毁引用留给对象。

如果您自己动态分配对象并将指针传递给std::shared_ptr构造函数，则只要没有强引用，即使仍有弱引用，也可以释放对象占用的内存。

Answer 2

现代IDE具有“查找用法”功能。 如果使用std::make_shared构造对象，则在搜索调用该对象的构造函数的位置时，IDE将不会显示使用std::make_shared位置。

Answer 3

如果您构建的对象将在对象的生命周期中共享多个实体，那么是的，您希望尽可能使用std :: make_shared。 有些地方可能是不可能的，如果你从别人那里获得指针; 例如，工厂可能会返回您希望存储在shared_ptr中的原始指针或std :: unique_ptr，从而阻止使用make_shared。

标题中的问题有点不同; 有很多原因你可能根本不想将shared_ptr用于你的对象。 如果生命周期实际上由多个对象共享，则应该只使用shared_ptr。 否则，首选stack分配对象或使用unique_ptr。