問題タブ [shared-ptr]

ブースト共有ポインターを返し、それらをパラメーターとして使用する DLL を C++ で開発することは有効ですか?

では、このような関数をエクスポートしても問題ありませんか?

特に、参照カウントは DLL の境界を越えて機能しますか、それとも exe と dll が同じランタイムを使用することが要件になりますか?

その意図は、オブジェクトの所有権に関する問題を克服することです。そのため、dll と exe の両方がオブジェクトを参照しなくなると、オブジェクトは削除されます。

shared_ptrの循環参照を見つけるためのヒント/コツはありますか？

これは私が見つけようとしているものの例です-残念ながら、コード内でループを見つけることができないようです。

私の現在のプロジェクトでは、boost::shared_ptrかなり広範囲に使用しています。

最近、私の仲間のチームメイトもを使い始めましweak_ptrた。どちらをいつ使うかわかりません。

weak_ptrこれとは別に、に変換したい場合はどうすればよいですかshared_ptr。ロックをオンにweak_ptrして作成するとshared_ptr、他のスレッドのコードに影響しますか？

これらのステートメントを含むファイルがある：

私はそれをこのように使うことができます：

しかし、私が望むように、このようにではありません：

getter関数を使用すると、次のエラーが発生します。

'Housekeeping :: TBFInstallation :: getTBFCmdHandler'：'this'ポインタを'const Housekeeping::TBFInstallation'から'Housekeeping:: TBFInstallation＆'に変換できません

ここで何が問題になっていますか？

クラスにいくつかのコンテナーがあります。たとえば、ヒープ上に存在するオブジェクトへの shared_ptr を含むベクターまたはマップです。

例えば

shared_ptr<const T>このクラスのパブリック インターフェイスを使用して、( を介して) shared_ptrs を const オブジェクトに返すこともあれshared_ptr<T>ば、呼び出し元がオブジェクトを変更できるようにすることもあります。

論理的な const の正確性が必要なので、メソッドを const としてマークすると、ヒープ上のオブジェクトを変更できません。

質問:

1) と の交換可能性に混乱していshared_ptr<const T>ますshared_ptr<T>。誰かがshared_ptr<const T>クラスに a を渡した場合、私は次のことを行いますか?

• コンテナとして保管するか、shared_ptr<T>それともshared_ptr<const T>コンテナ内に保管しますか?
• また
• マップ、ベクター タイプ (insert_element( shared_ptr<const T>obj) など) を変更しますか?

2) 次のようにクラスをインスタンス化する方が良いMyExample<const int>ですか? shared_ptr<int>?を返すことはできないため、これは過度に制限されているように思えます。

ゲームとそれに付随するエンジンを C++ で書いています。エンジンは、単純な埋め込みスクリプト言語を使用した自動化に大きく依存しています。スクリプトは、オブジェクト クラスを作成し、それらにイベント リスナーを定義し、それらからインスタンスを生成できます。現在、インスタンスの存在を維持するには、インスタンスをスクリプト グローバル識別子にバインドする必要があります。これの明らかな結果は、無名オブジェクトが存在できないということです。これは、最も一般的なものです。

現在、インスタンスは を使用して管理されていますstd::set<Instance*, spatial_sort>。ここで、spatial_sortは、レンダリングと衝突検出のために、インスタンスを位置でソートするファンクタです。インスタンスは、現在の位置をヒントとして使用して、フレームごとに削除され、再挿入されます。これは、インスタンスが 50 分の 1 秒で大きく移動する可能性が低いという前提の下で行われます。インスタンスにフラグが設定されている場合、deadフラグはセットから消去されます。Instanceコンストラクタとデストラクタは、それぞれinsert(this)とを呼び出しerase(this)ます。

匿名インスタンスを許可するために、セットを a に変更したいと考えていますstd::set<boost::shared_ptr<Instance>, spatial_sort>。これによりInstance、インスタンスの所有権を共有し、インスタンスが自分自身を破壊するまで存在を維持できます。残念ながら、 への呼び出しinsert()はコンストラクターに配置する必要があるため、へのshared_from_this()を取得するためには機能しません。基本クラスを介してすでに継承されていることはまったく問題ではありません。shared_ptrInstanceInstanceboost::enable_shared_from_this<>

誰でも適切な回避策を推奨できますか?

編集：

最初にすべきことを行い、クラスの動作を と の 2 つのクラスに分割しましInstanceた。スクリプト内の式は、新しい にa を返します。オブジェクト自体は を使用して管理されることはないため、アニメーションの終了、レベルの終了などの適切なイベントに応答して自殺する責任があります。InstanceReferencenew SomeClassReferenceInstanceInstanceshared_ptr

助けてくれてありがとう！リファクタリングは、うまく機能する場合と同じくらい優れたソリューションです。

こんにちは、boost/1.41.0 を使用しています。shared_ptr を逆シリアル化しようとすると、次のコードでコンパイル エラーが発生します。正常にコンパイルされたシリアル化部分。これが私のコードのバグなのか、ブーストの一般的な問題なのか、誰かにアドバイスしてもらえますか? ありがとう。

ヤンチャオ

私は現在、に大きく依存するアプリケーションをまとめており、shared_ptrこれまでのところすべてがうまくいっているようですshared_ptr.

最も認識されている問題の 1 つは、循環依存関係です。これらの問題は、チェーンのオブジェクトの有効期間に影響を与えないshared_ptrを格納することで解決できます。weak_ptrただし、外部オブジェクトへのポインターを a 経由で保存する必要がある場合に頭を悩ませていますweak_ptr-それが禁止されているのか、推奨されていないのか、それとも安全なのかわかりません

次の図は、私が何を意味するかを説明しています (黒い矢印は を示しshared_ptr、破線は を示しますweak_ptr)。

代替テキスト http://img694.imageshack.us/img694/6628/sharedweakptr.png

• 親にはshared_ptr、 を使用して親を指す 2 つの子へのが含まれますweak_ptr。
• 最初の子のコンストラクターで、親を介して2 番目の子weak_ptrへのポインターを取得し、それをローカルに保存します。

コードは次のようになります。

私はこれをテストしましたが、問題なく動作しているようです(メモリ リークの報告はありません) が、私の質問は次のとおりです: これは安全ですか? もしそうでなければ、なぜですか？

の使用に関するベスト プラクティスについていくつか質問がありshared_ptrます。

質問1

コピーはshared_ptr安いですか？それとも、自分のヘルパー関数への参照として渡し、値として返す必要がありますか? 何かのようなもの、

質問2

boost::make_sharedを構築するために使用する必要がありshared_ptrますか? はいの場合、どのような利点がありますか? また、パラメーターのないコンストラクターがないmake_shared場合、どのように使用できますか?T

質問 3

使い方はconst foo*？これを行うための2つのアプローチを見つけました。

また

質問 4

オブジェクトに戻って確認するNULLにはどうすればよいですか? shared_ptrのようなものですか、

どんな助けでも素晴らしいでしょう。

make_shared<T>()を使用する代わりに使用することの欠点はありますかshared_ptr<T>(new T)。

ブーストドキュメントの状態

特定のタイプのオブジェクトを作成し、それにshared_ptrを返すファクトリ関数に対するユーザーからの要求が繰り返されています。利便性とスタイルに加えて、このような関数は、オブジェクトとそれに対応する制御ブロックの両方に単一の割り当てを使用でき、shared_ptrの構築オーバーヘッドのかなりの部分を排除できるため、例外安全性とかなり高速です。これにより、shared_ptrに関する主な効率性の不満の1つが解消されます。