我无法想到
的任何情况std::shared_ptr<Object> obj(new Object("foo", 1));
将优先于
auto obj = std::make_shared<Object>("foo", 1);
后者总是会产生更好的局部性并减少内存碎片。是否有任何情况，您希望（或被迫）使用第一种形式，除了与返回原始指针的代码接口？
答案 0 :(得分：18)
后者总是会产生更好的局部性并减少内存碎片。
不总是。鼓励实现对引用计数对象和引用计数使用单个分配，但不是 required 。
为什么您可能不想使用std::make_shared？考虑一下你希望std::shared_ptr拥有一个大的动态分配对象的情况，并且你知道对这个对象的弱引用可能比对象的强引用更长（可能有很多弱点）引用，只有一两个短命的强引用。）
在这种情况下，std::make_shared将是一个糟糕的选择，假设它分配一个拥有对象和引用计数的块：分配的块（大，请记住）不能销毁，直到有没有强烈或弱的引用留给对象。
如果您要自己动态分配对象并将指针传递给std::shared_ptr构造函数，则只要没有强引用，对象占用的内存就会被释放，即使仍然存在弱引用。
答案 1 :(得分：0)
如果您正在构建一个在对象的生命周期内有多个实体共享的对象，那么是的，您希望尽可能使用std :: make_shared。有些地方可能是不可能的，如果你从别人那里获得指针;例如，工厂可能会返回您希望存储在shared_ptr中的原始指针或std :: unique_ptr，从而阻止使用make_shared。
标题中的问题有点不同;有很多原因你可能根本不想将shared_ptr用于你的对象。如果生命周期实际上由多个对象共享，则应该只使用shared_ptr。否则，首选stack分配对象或使用unique_ptr。
答案 2 :(得分：0)
现代IDE具有“查找用法”功能。如果使用std::make_shared构造对象，则在搜索调用该对象的构造函数的位置时，IDE将不会显示使用std::make_shared的位置。