有什么情況我不會使用std :: make_shared嗎？

Question

從我所做的研究來看，聽起來std::make_shared是構造std::shared_ptr的首選方式。 特別是因為：

1. 與使用new執行至少兩次相比，它只執行一次內存分配。
2. 如果ctor傳遞給make_shared拋出，那么它就不會泄漏，就像新的一樣。

我的問題是，假設我想要一個shared_ptr，我應該總是使用make_shared ，還是有new的首選的情況？

Answer 1

由於計數器和對象共享相同的分配，它們也共享相同的釋放。

計數器必須持續到最后一個shared_ptr和weak_ptr消失。 如果你有一個具有持久weak_ptr的大對象（或許多小對象），如果你通過make_shared分配shared_ptr ，這可能會導致內存爭用。

其次，如果你有第三方API給你指針或資源句柄，並且可能有自己的dispose功能， make_shared既不適合也不可能在每種情況下使用。 創建自己的make_函數可以防止雜亂的細節讓你處理這個問題，並處理異常的角落情況。

最后，雖然共享指針非常棒，但它們也非常強大。 我經常想要一個unique_ptr甚至是boost::scoped_ptr ，或者一個侵入式引用計數指針等來表示所有權。 shared_ptr應該僅在情況實際涉及資源的共享所有權時使用：使用它因為它“容易”傾向於最終得到與意大利面條代碼相當的資源。

Answer 2

您可能必須處理返回動態分配對象的遺留代碼。 在這種情況下，您需要將std::shared_ptr<T> ctor與指針參數一起使用。 使用std::make_shared並不是優選的，但它允許您使用遺留代碼的所有std::shared_ptr<T>優點。

我知道這並不等同於直接使用std::shared_ptr<T> ctor和new ，但它是std::shared_ptr<T>的有效用例，其中make_shared無法使用。

Answer 3

我對你的問題的解釋有點不確定。 我假設使用shared_ptr<T>是合理的; 我只能說你為什么不想在第一時間使用shared_ptr第二個Yakk 。

有一種情況是你不能使用make_shared或allocate_shared來構造shared_ptr但你需要使用相應的ctor：如果你需要傳入一個自定義刪除器，請參閱shared_ptr的ctors （3）和（4）。

Answer 4

我在使用私有構造函數的類（來自靜態工廠方法）上使用make_shared時遇到了問題。 我認為沒有一個簡單的解決方案。

Answer 5

我應該總是使用make_shared，還是有新的首選的情況

當我們將裸指針存儲在由其他人分配的shared_ptr時，不允許make_shared 。 它只能調用public構造函數。 但是也有一些編譯器有關訪問受保護的構造一些報道使用make_shared 這樣 。