問題タブ [shared-ptr]

または、それを行う必要がある場合は、shared_ptr を使用する必要がありますか?

アプリケーション全体で std::tr1::shared_ptr を広範囲に使用しています。これには、オブジェクトを関数の引数として渡すことも含まれます。次の点を考慮してください。

shared_ptr を介してデータセット オブジェクトを渡すと、f および g 内での存在が保証されますが、関数は何百万回も呼び出される可能性があり、多くの shared_ptr オブジェクトが作成および破棄されます。最近実行したフラット gprof プロファイルのスニペットを次に示します。

そのため、実行時間の約 17% が shared_ptr オブジェクトの参照カウントに費やされました。これは正常ですか？

私のアプリケーションの大部分はシングル スレッドであり、一部の関数を次のように書き直すことを考えていました。

呼び出しを置き換える

と

プログラムの流れがf()内にある間、オブジェクトが破壊されないことが確実にわかっている場所で。しかし、一連の関数シグネチャ/呼び出しを変更する前に、shared_ptr を渡すことによる典型的なパフォーマンス ヒットがどのようなものかを知りたいと思いました。頻繁に呼び出される関数には shared_ptr を使用しないようです。

任意の入力をいただければ幸いです。読んでくれてありがとう。

-アルテム

更新:一部の関数を accept に変更した後const Dataset&、新しいプロファイルは次のようになります。

デストラクタの呼び出し数がコピー コンストラクタの呼び出し数よりも少ないことに少し困惑していますが、関連するランタイムの減少には全体的に非常に満足しています。アドバイスをくれてありがとう。

それはほとんどそれです。メモリを割り当てて、void*を受け取る関数に渡す必要があります。shared_ptrを使用したいのですが、その方法がわかりません。

コンストラクター内に他の子オブジェクトを作成するオブジェクトがあり、「this」を渡して、子がポインターを親に戻すことができるようにします。std :: auto_ptrまたはrawポインターのより安全な代替手段として、プログラミングでboost::shared_ptrを広範囲に使用しています。したがって、子には、などのコードがshared_ptr<Parent>あり、boostは親が子shared_from_this()に与えることができるメソッドを提供します。

私の問題はshared_from_this()、コンストラクターで使用できないことです。これは、実際には犯罪ではありません。何をしているのかを理解し、制限を気にしない限り、「this」をコンストラクターで使用するべきではないからです。

GoogleのC++スタイルガイドでは、コンストラクターはメンバー変数を初期値に設定するだけでよいと述べています。複雑な初期化は、明示的なInit（）メソッドで行う必要があります。これにより、「コンストラクター内のこの」問題だけでなく、他のいくつかの問題も解決されます。

私を悩ませているのは、あなたのコードを使用している人々は、あなたのオブジェクトの1つを構築するたびにInit（）を呼び出すことを忘れないでください。これを強制するために私が考えることができる唯一の方法は、Init（）がすでにすべてのメンバー関数の先頭で呼び出されているというアサーションを持つことですが、これは書くのが面倒で実行が面倒です。

途中でこの問題を解決するイディオムはありますか？

これは私のコードで一般的なパターンになりつつあります.A.「重い」またはB.クリティカルセクションなどのオペレーティングシステムリソースであるために、コピー不可にする必要があるオブジェクトを管理する必要がある場合:

このようにして、shared_ptr は参照カウントの頭痛のResource種を処理し、コピー可能にすることができます。

Implementationしかし、 boost の侵入コンテナのように、何らかの方法でそのデータを内部に移動できれば、shared_ptr の参照カウントなどを個別に割り当てるオーバーヘッドを節約できそうです。

これにより、時期尚早の最適化ハックルが一部の人々を悩ませている場合、現在のプロジェクトにはこれが必要ないことに実際に同意します。しかし、それが可能かどうか興味があります。

C++11の新機能を試すペットプロジェクトがあります。私はCの経験がありますが、C++にはかなり慣れていません。ベストプラクティスを習得するために（たくさん読む以外に）、いくつかの厳密なコンパイラーパラメーターを有効にしました（GCC 4.4.1を使用）。

これは私にとってはうまくいきました。今まで、私はすべての障害を解決することができました。しかし、私にはが必要でenable_shared_from_thisあり、これが私に問題を引き起こしています。コードをコンパイルすると、次の警告（私の場合はエラー）が表示されます（おそらくによってトリガーされます-Weffc++）。

したがって、基本的に、私はこの実装に少しバグがありますenable_shared_from_this。理由は次のとおりです。

• サブクラス化を目的としたクラスのデストラクタは、常に仮想である必要があります、IMHO。
• デストラクタは空ですが、なぜそれがあるのですか？
• を参照してインスタンスを削除したいと思う人はいないと思いますenable_shared_from_this。

しかし、私はこれに対処する方法を探しているので、私の質問は本当に、これに対処する適切な方法はありますか？そして：私はこのデストラクタが偽物であると考えるのは正しいですか、それともそれに本当の目的がありますか？

私はクラスモデルを持っています：

Deckから継承しCardStackます。

_stack[0]私は行くことによって指し示すのと同じことを指し示すことを試みました_deck：

の割り当て_deckは_stack[0]、コピーが作成される結果になるよう_deckです。_stack[0]（変更しても変更が発生しないため、これを知ってい_deckます。）同じことを指すようにするにはどうすればよいですか？

わかりました-コピーコンストラクタは呼び出されていません。私はそれを実装し、それが呼び出されるかどうかを確認することによってこれを検証しました-そうではありません。

ただし、CardStackオブジェクトを操作する関数があります。

今-私が電話するとき：

私はこの出力を取得します（ここで、aのstd :: coutCardStackはそのスタックのサイズを出力します）：

...だから私は（間違って？）_stack[DECK]何か違うことを指していると結論付けました。

デッキ

ブースト 1.40.0 の共有ポインターをオートコンプリートする intellisense を取得するのに問題があります。(Boost 1.33.1 では問題なく動作します。) 以下は、オートコンプリートが機能しない単純なサンプル プロジェクト ファイルです。

shared_ptr を右クリックして [定義に移動] を実行すると、 の shared_ptr クラスの前方宣言が表示され<boost/exception/exception.hpp>ます。にある実際の定義には至りません<boost/smart_ptr/shared_ptr.hpp>。ただし、コンパイルは正常に行われ、「boost::」のオートコンプリートは正常に機能します。また、オートコンプリートは、boost::scoped_ptr と boost::shared_array に対して正常に機能します。

何か案は？

次の点を考慮してください。

boost::make_shared<DirectoryIteratorImpl>DirectoryIteratorは の友人であるため、を呼び出すことができるようですDirectoryIteratorImpl。ただし、DirectoryIteratorImpl のコンストラクターがプライベートであるため、このコードはコンパイルに失敗します。

このクラスは、クライアントがDirectoryIterator決して触れてはならない内部実装の詳細であるため、コンストラクターを非公開にしておくことができればよいでしょう。

これは私の根本的な誤解ですか、それとも、呼び出しをコンパイルするために、make_sharedある種のブーストピースをマークする必要がありますか?friend