`std::make_shared` は `std::shared_ptr` を直接構築するより効率的ですか?

std::make_shared の効率

std::make_shared 関数を使用して生のポインターから共有ポインターを設計する場合、違いがありますコンストラクターを使用して std::shared_ptr を直接作成する場合と比較して効率が高くなります。以下に段階的な説明を示します。

std::make_shared:

1. 制御ブロック (参照カウントとその他のメタデータを管理する) の両方にメモリを割り当てます。
2. 割り当てられたオブジェクトを使用して std::shared_ptr オブジェクトを構築します。メモリ.

ダイレクト std::shared_ptr コンストラクタ:

1. new を使用してオブジェクトにメモリを割り当てます。
2. メモリを割り当てます制御ブロック。
3. を構築します。

ご覧のとおり、std::make_shared は 1 つの割り当て (制御ブロックとオブジェクトの両方) を実行しますが、ダイレクト コンストラクター メソッドは 2 つの割り当てを実行します。割り当て (1 つはオブジェクト用、もう 1 つは制御ブロック用)。この割り当ての違いは、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;
}</object2></object1></object2></object1>

std::make_shared がないと、引数の評価順序は指定されず、Object1 の割り当てが失敗すると、Object2 のメモリがリークします。 std::make_shared を使用すると、この例外安全性の問題が解決されます。

std::make_shared の欠点

std::make_shared の潜在的な欠点の 1 つは、オブジェクトのメモリの早期割り当て解除を防ぎます。直接コンストラクター メソッドとは異なり、std::make_shared は制御ブロックとオブジェクト用に単一のメモリ ブロックを作成します。これは、オブジェクトと制御ブロックの両方のメモリを独立して割り当て解除できないことを意味します。オブジェクトを指す弱いポインタがある場合、オブジェクト自体が使用されなくなった後でも制御ブロックが生きたままになる可能性があり、メモリの保持につながる可能性があります。

以上が`std::make_shared` は `std::shared_ptr` を直接構築するより効率的ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。