C++11使用make_shared的優勢和劣勢

C++11 中引入了智能指針, 同時還有一個模板函數 std::make_shared 可以返回一個指定類型的 std::shared_ptr, 那與 std::shared_ptr 的構造函數相比它能給我們帶來什么好處呢 ?

優點

效率更高

shared_ptr 需要維護引用計數的信息,

強引用, 用來記錄當前有多少個存活的 shared_ptrs 正持有該對象. 共享的對象會在最后一個強引用離開的時候銷毀( 也可能釋放).
弱引用, 用來記錄當前有多少個正在觀察該對象的 weak_ptrs. 當最后一個弱引用離開的時候, 共享的內部信息控制塊會被銷毀和釋放 (共享的對象也會被釋放, 如果還沒有釋放的話).

如果你通過使用原始的 new 表達式分配對象, 然后傳遞給 shared_ptr (也就是使用 shared_ptr 的構造函數) 的話, shared_ptr 的實現沒有辦法選擇, 而只能單獨的分配控制塊:

 
              auto p = new widget(); shared_ptr sp1{ p }, sp2{ sp1 };

如果選擇使用 make_shared 的話, 情況就會變成下面這樣:

 
              auto sp1 = make_shared(), sp2{ sp1 };

內存分配的動作, 可以一次性完成. 這減少了內存分配的次數, 而內存分配是代價很高的操作.

關於兩種方式的性能測試可以看這里 Experimenting with C++ std::make_shared

異常安全

看看下面的代碼:

 
              void F(const std::shared_ptr<Lhs>& lhs, const std::shared_ptr<Rhs>& rhs) { /* ... */ }  F(std::shared_ptr<Lhs>(new Lhs("foo")),  std::shared_ptr<Rhs>(new Rhs("bar")));

C++ 是不保證參數求值順序, 以及內部表達式的求值順序的, 所以可能的執行順序如下:

new Lhs(“foo”))
new Rhs(“bar”))
std::shared_ptr
std::shared_ptr

好了, 現在我們假設在第 2 步的時候, 拋出了一個異常 (比如 out of memory, 總之, Rhs 的構造函數異常了), 那么第一步申請的 Lhs 對象內存泄露了. 這個問題的核心在於, shared_ptr 沒有立即獲得裸指針.

我們可以用如下方式來修復這個問題.

 
              auto lhs = std::shared_ptr<Lhs>(new Lhs("foo")); auto rhs = std::shared_ptr<Rhs>(new Rhs("bar")); F(lhs, rhs);

當然, 推薦的做法是使用 std::make_shared 來代替:

 
              F(std::make_shared<Lhs>("foo"), std::make_shared<Rhs>("bar"));

缺點

構造函數是保護或私有時,無法使用 make_shared

make_shared 雖好, 但也存在一些問題, 比如, 當我想要創建的對象沒有公有的構造函數時, make_shared 就無法使用了, 當然我們可以使用一些小技巧來解決這個問題, 比如這里 How do I call ::std::make_shared on a class with only protected or private constructors?

對象的內存可能無法及時回收

make_shared 只分配一次內存, 這看起來很好. 減少了內存分配的開銷. 問題來了, weak_ptr 會保持控制塊(強引用, 以及弱引用的信息)的生命周期, 而因此連帶着保持了對象分配的內存, 只有最后一個 weak_ptr 離開作用域時, 內存才會被釋放. 原本強引用減為 0 時就可以釋放的內存, 現在變為了強引用, 若引用都減為 0 時才能釋放, 意外的延遲了內存釋放的時間. 這對於內存要求高的場景來說, 是一個需要注意的問題. 關於這個問題可以看這里 make_shared, almost a silver bullet