在構造對象時是否有任何理由不使用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。