問題タブ [make-shared]

gcc 4.6.2 を使用すると、コンストラクターが例外をスローした場合、make_shared() は役に立たないバックトレースを返します (何らかの再スローが原因と思われます)。タイピングを少し節約するために make_shared() を使用していますが、これはショーストッパーです。通常のバックトレースを可能にする代わりのmake_shrd()を作成しました。gdb 7.3.1 を使用しています。

私はそれが心配です：

1. make_shared() の下の悪いバックトレースは、どういうわけか私自身のせいです
2. 私の代わりの make_shrd() は微妙な問題を引き起こします。

ここにデモがあります：

以下でコンパイル:

以下でデバッグ:

make_shared() バックトレースは、例外の時点までのスタックを表示しないジャンクです。他のすべてのオプションは、適切なバックトレースを提供します。

助けと提案を前もってありがとう。

私はC++11を試したり、C ++ 11から実験しshared_ptrたりmake_sharedして、小さなおもちゃの例をプログラムして、を呼び出したときに実際に何が起こっているかを確認しましたmake_shared。インフラストラクチャとして、XCode4内のllvm stdc++ライブラリとともにllvm/clang3.0を使用していました。

次に、出力を見てください。

make_sharedを使用してsmart_ptrを作成します...

コンストラクタmake_shared

コンストラクターをコピーします。

コンストラクターをコピーします。

デストラクタ

デストラクタ

make_sharedを使用してsmart_ptrを作成します：done。

new...を使用してsmart_ptrを作成します。

新しいコンストラクタ

new：doneを使用してsmart_ptrを作成します。

デストラクタ

デストラクタ

make_sharedコピーコンストラクタを2回呼び出しているようです。Objectレギュラーを使用してメモリを割り当てる場合、newこれは発生せず、1つだけObjectが構築されます。

私が疑問に思っているのは次のとおりです。^{（1、2）を}make_shared使用するよりも効率的だと聞いてい^ます。1つの理由は、同じメモリブロックで管理されるオブジェクトと一緒に参照カウントを割り当てるためです。OK、要点はわかりました。もちろん、これは2つの個別の割り当て操作よりも効率的です。newmake_shared

それどころか、なぜこれがのコピーコンストラクターへの2回の呼び出しのコストを伴う必要があるのか​​理解できませんObject。このため、すべての場合に使用するmake_shared割り当てよりも効率的であるとは確信していません。私はここで間違っていますか？さて、1つはのための移動コンストラクターを実装することができますが、それでもこれが単にを割り当てるよりも効率的であるかどうかはわかりません。少なくともすべての場合ではありません。コピーが参照カウンターにメモリを割り当てるよりも安価である場合は、それが当てはまります。しかし、内部参照カウンターは、いくつかのプリミティブデータ型を使用して実装できますよね？newObjectObjectnewObjectshared_ptr

make_shared概説されたコピーのオーバーヘッドにもかかわらず、なぜ効率の観点から進むべきかを助け、説明できますか？

boost :: make_sharedを初めて使用して、共有ポインターが指すオブジェクトを作成しています。主な理由は、コードが遅すぎて、単一の割り当てがパフォーマンスの向上に本当に役立ったためです。

いくつかのメモリリークを「難しい手動の方法」で修正した後、アプリケーションの特定のポイントでまだ生きているオブジェクトを数えるためだけに、関連するすべてのクラスの新しい演算子をオーバーライドすることで、単純なメモリリーク検出器を実装することにしました。私はこれを数回実装しましたが、コードがオブジェクトを検出しなくなったことに驚きました。

make_sharedのブーストWebサイトのドキュメントから次の理由により、「通常の」演算子newではなく「placementnew」をオーバーライドするだけでよいと考えました。

"効果：タイプTのオブジェクトに適したメモリを割り当て、配置new式new（pv）T（）またはnew（pv）T（std :: forward（args）...）を介してその中にオブジェクトを構築します。allocate_sharedのコピーを使用してメモリを割り当てます。例外がスローされた場合、効果はありません。」

ただし、新しい配置も呼び出されていません。動作を再現するための小さなテストプログラムを作成しました。

これにより、次の出力がレンダリングされます。

出力の3行目に「新しい非スロー配置をテストする」と期待していました。行動はどうあるべきだと思いますか？make_sharedのドキュメントによると、配置を私のテストクラスの新しい演算子と呼ぶことに同意しますか？それとも私はそれを誤解しましたか？

もちろん、ブーストの実装をローカルにコピーして、配置の新しい演算子に呼び出しを追加することもできます。しかし、それは適切でしょうか、それとも新しい配置構文の意図されたセマンティクスに違反するのでしょうか？

あなたの時間とあなたの助けを前もって感謝します。

Visual Studio 2010/2011に可変個引数テンプレートがない場合（まだ！）、多くのパラメーターを受け取るコンストラクターは問題になる可能性があります。たとえば、以下はコンパイルされません。

、13個のパラメーターがあり、make_sharedはarg0からarg9に制限されていると思います。明らかな回避策は2つの部分からなる構造ですが、私はこれを避けたいと思っていました。make_sharedの代わりにnewを使用する以外に、ここで他の可能性はありますか？

ありがとう。

shared_ptr メンバー変数を初期化する場合:

対。

make_shared バージョンは使用できますか? いつも最初のバージョンが表示されるようですが、どちらが優先されますか?

std::make_shared を使用して「this」をコンストラクターに渡そうとしています

例：

ただし、これは正しく機能しません。これを引数として適切に渡す方法はありますか?

I am trying to switch my code to use make_shared<type>() but I have a lot of incomplete types (complete at the time of creation) and was wondering if there is anyway make_shared would work with incomplete types or allow me to pass a deleter type.

I looked around and didn't find any posts related to this so either this just works ?? or I am overlooking something basic.

Above is the macro I use to create new objects. Would like to convert this to

EDIT: Just to clarify I wanted to ask if I could pass a deleter type to the shared_ptr created with make_shared

Boost のmake_shared()関数は、shared_ptr.

make_scoped()同等のものがないのはなぜですか？一般的なベストプラクティスはありますか?

これは、私にとって安全ではないと思われるboost::scoped_ptrドキュメントのコード例です。

このコード行は、次の 3 つのことを順番に実行します。

• にヒープメモリを割り当てますShoe
• のコンストラクターを呼び出しますShoe
• のコンストラクターを呼び出しますboost::scoped_ptr<Shoe>

コンストラクターがShoe例外をスローすると、 メモリ リークが発生します。 (R. Martinho Fernandes の回答を参照)scoped_ptrまだ構築されていないため、解放は処理されません。

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

2 つのクラスを考える

main()これで、次のように実行できます。

boostライブラリを使用したバージョン

バージョンを使用する際の私の質問は、boostこの方法で使用しても問題ないかどうか、つまり、両方のバージョンを同じ方法で使用できるかどうか、または何か特別なことをする必要があるかどうかです (ブーストの内部についてはあまり知りません)。

私はここでそれを読みました：

make_sharedは、参照制御ブロックを実際のオブジェクトと一緒に1つの動的割り当てで割り当てるため、（実際には）より効率的です。対照的に、ネイキッドオブジェクトポインタを受け取るshared_ptrのコンストラクタは、参照カウントに別の動的変数を割り当てる必要があります

std::make_sharedを使用して作成されたstd::shared_ptrのベクトルは、データ（制御ブロックと実際のポインターのデータ）が1つのチャンクにあるため、「キャッシュフレンドリー」になるということですか？

私のユースケースは、オブジェクトが指す100000個の共有ポインタのベクトルが14バイトです。