なぜboostにmake_scoped（）がないのですか？

Question

ブーストのmake_shared()関数は、shared_ptrを作成しようとする際に例外から安全であることが保証されています。

make_scoped()はなぜ同じですか？共通のベストプラクティスはありますか？ここで

は私には安全ではないと思われるboost::scoped_ptr documentationからのコードの例です：

boost::scoped_ptr<Shoe> x(new Shoe); 

このコード行は順番にこれら三つを行います。

• Shoeのヒープ・メモリを割り当て
• のコンストラクタを呼び出すShoe
• はShoeのコンストラクタが例外をスローした場合、 メモリがリークされます boost::scoped_ptr<Shoe>

のコンストラクタを呼び出します。 （R. Martinho Fernandesの回答を参照）scoped_ptrはまだ構築されていないため、割り当て解除を処理しません。

これは見落としですか？それとも、私が気付かなかった解決策がありますか？

Answer 1

コンストラクタが失敗した場合、メモリはリークされません。それはnewのセマンティクスの一部だ、関与なしスマートポインタ：make_sharedによって提供さ

struct Foo { Foo() { throw 23; } }; 
new Foo(); // no memory leaked 

追加例外の安全性は、あなたが2 shared_ptr式のsおよびを初期化しているときに、2つの初期化がの配列を決定していないから来ています関数呼び出しの引数の場合のように：

struct Bar { 
    Bar(bool fail) { 
     if(fail) throw 17; 
    } 
} 
f(shared_ptr<Bar>(new Bar(true)), shared_ptr<Bar>(new Bar(false))); 

new Bar(true)、shared_ptr<Bar>(new Bar(true))、new Bar(false)との評価の間にはシーケンシングがないので、では、次のようなことが起こる可能性があります。

1. 評価され、成功しました。
2. new Bar(true)評価され、失敗します。この評価の結果としてメモリがリークすることはありません。

いいえshared_ptrこの時点では、No＃1で割り当てられたメモリがリークされるようになりました。

Answer 2

シューズがスローされた場合、シューズは構築されないので、scoped_ptrは実際に行うことができません。いいえ？ scoped_ptr xはスタック上にあり、スコープ出口でクリーンアップされます。

Answer 3

scoped_ptr predatesは移動セマンティクスであり、設計上はコピーできません。したがって、make_scopedは、関数からオブジェクトを返すために、その型は移動可能でもコピー可能でもなければならないため、実装することは不可能です。