首頁 > 後端開發 > C++ > `std::make_shared` 比直接建構 `std::shared_ptr` 更有效率嗎?

`std::make_shared` 比直接建構 `std::shared_ptr` 更有效率嗎?

Mary-Kate Olsen
發布: 2025-01-04 03:39:40
原創
986 人瀏覽過

Is `std::make_shared` More Efficient Than Directly Constructing `std::shared_ptr`?

std::make_shared 的效率

使用std::make_shared 函數從原始指標設計共用指標時,有一個差異與使用構造函數直接建立std::shared_ptr 相比,效率更高。這是逐步說明:

std::make_shared:

  1. 為控制區塊(管理引用計數和其他元資料)分配記憶體) 和物件。
  2. 使用分配的物件建構std::shared_ptr 物件

直接std::shared_ptr 建構子:

  1. 使用為對象分配記憶體。
  2. 為物件分配記憶體控制區塊。
  3. 建構std::shared_ptr 物件

如您所見,std::make_shared 執行一次分配(對於控制區塊和物件),而直接建構函式方法執行兩次分配(一次用於控制區塊和對象)對象,另一個用於控制區塊)。這種分配上的差異導致使用 std::make_shared 時效率更高。

異常安全

在 C 17 之前,使用 std::make_shared 也更例外 -安全的。考慮下面的程式碼:

void f(const std::shared_ptr<Object1>& obj1, const std::shared_ptr<Object2>& obj2) {
  // ...
}

int main() {
  f(std::shared_ptr<Object1>(new Object1()), std::shared_ptr<Object2>(new Object2()));
  return 0;
}
登入後複製

如果沒有 std::make_shared,參數的計算順序是未指定的,如果 Object1 的分配失敗,Object2 的記憶體將被洩漏。使用 std::make_shared,可以解決這個異常安全性問題。

std::make_shared 的缺點

std::make_shared 的一個潛在缺點是它可以防止過早釋放物件的記憶體。與直接建構函式方法不同,std::make_shared 為控制區塊和物件建立單一記憶體區塊。這意味著物件和控制區塊的記憶體不能單獨釋放。如果存在指向該物件的弱指針,即使該物件本身不再使用,它​​們也可以使控制塊保持活動狀態,從而可能導致記憶體保留。

以上是`std::make_shared` 比直接建構 `std::shared_ptr` 更有效率嗎?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板