私が行った調査から、std::make_sharedを構築する好ましい方法のように思えstd::shared_ptrます。具体的な理由:
new少なくとも 2 つのメモリ割り当てを実行 する using とは異なり、これは 1 つのメモリ割り当てのみを実行します。私の質問は、shared_ptr が必要であると仮定して、常に を使用する必要があるか、または が好まれるmake_shared場合があるかということです。new
カウンターとオブジェクトは同じ割り当てを共有するため、同じ割り当て解除も共有します。
カウンターは最後まで存続し、消える必要がshared_ptrありweak_ptrます。永続的な s を持つ大きなオブジェクト (または多くの小さなオブジェクト) がある場合、 を介しweak_ptrて s を割り当てると、メモリの競合が発生する可能性があります。shared_ptrmake_shared
第 2 に、ポインターまたはリソース ハンドルを渡すサード パーティ API があり、独自の破棄機能を持っている可能性があるmake_shared場合、すべてのケースで適切でも使用可能でもありません。独自のmake_関数を作成すると、煩雑な詳細を邪魔にならないようにすることができ、この問題に対処でき、例外的なコーナーケースにも対処できます。
最後に、共有ポインターはすばらしいものですが、あまりにも強力です。unique_ptr所有権を表すためにやboost::scoped_ptr、侵入型の参照カウント ポインターなど を必要とすることがよくあります。状況が実際にリソースの共有shared_ptr所有権を伴う場合にのみ使用する必要があります。「簡単」であるため、無意味に使用すると、スパゲッティコードと同等のリソースになる傾向があります。
動的に割り当てられたオブジェクトを返すレガシー コードを処理する必要がある場合があります。その場合、std::shared_ptr<T>ctor をポインター パラメーターと共に使用する必要があります。使用するのは好ましくありませんが、レガシー コードでstd::make_sharedすべての利点を使用できます。std::shared_ptr<T>
std::shared_ptr<T>これはctorをnew直接使用することと厳密には同等ではないことはわかっていますが、使用できないstd::shared_ptr<T>場合の有効なユースケースです。make_shared
あなたの質問の解釈について、私は少し確信が持てません。shared_ptr<T>;を使用することは正当であると想定しています。そもそもYakkを使用したくない理由については、Yakkに次ぐことしかできませんshared_ptr。
make_sharedorallocate_sharedを使用して を構築できない状況が 1 つありますがshared_ptr、対応する ctor を使用する必要がありますshared_ptr。
常にmake_sharedを使用する必要がありますか、それともnewが優先される場合がありますか
make_sharedshared_ptr他の誰かによって割り当てられたネイキッド ポインターを格納している場合は許可されません。publicコンストラクターのみを呼び出すことができます。ただし、このようにmake_shared を使用して保護されたコンストラクターにアクセスすることについて、一部のコンパイラーでいくつかのレポートがあります。