問題タブ [weak-ptr]

と を使用しCreatureて、アプリケーションの一部で作成および所有されるオブジェクトのコレクションがあります。std::make_sharedstd::shared_ptr

また、を使用して、オブジェクトCreature内の 0 または 1 の選択を追跡します。Worldstd::weak_ptr<Creature>

の呼び出し元はGetSelection、ポインターが空かどうかをチェックする責任があります。そうである場合、それは現在選択がないことを意味します。

これはすべて私の好みで完全に機能します。選択したものCreatureが自然な原因で (アプリケーションの他の場所で) 死ぬと、何も選択されなかったかのように再びGetSelectiona を返し始めます。nullptr

ただし、その場合、メンバーはまだの制御ブロックWorld::selectionを指しています。オブジェクトを作成するstd::shared_ptrために使用しているため、これは非常に大きくなる可能性があります (オブジェクトは適切なタイミングで適切に破棄されましたが、そのためのメモリはまだ割り当てられていることに気付きました)。これに変更することを検討しています：std::make_sharedCreatureCreatureGetSelection

これにより、不要になったことに気付くとすぐにメモリが解放されます。厄介なことに、このバージョンのGetSelectionはconst.

私の質問:

1. GetSelectionこの状況でベスト プラクティスと見なされるのは、どのバージョンのですか?

2. テンプレート化されたコードで同様のことが起こった場合、答えは変わりますsizeof(T)か? または、C++ 14 ではどこstd::make_shared<T[]>に関与する可能性がありますか?

3. std::weak_ptr<T>::expired2 番目のバージョンが常に最適である場合、自分でそれを行わない理由は何lockですか?

std::weak_ptr があります。基になるオブジェクトを使用する前に、shared_ptr を取得するためにロックします。

通常、これで問題なく動作します。ただし、ロックの呼び出し中にアクセス違反が発生することがあります。

私の推測では、基になっているポインターは削除されていますが、weak_ptr についての私の理解では、この場合、lock は nullptr を返す必要があります。タイプを誤用していませんか？そうでない場合、これをデバッグするにはどうすればよいですか?

私は持っている：

そして B 関数で:

したがって、問題は次のとおりです。

1. コンパイラ エラー:error C2440: 'static_cast' : cannot convert from 'B *const ' to 'A *'
2. コンパイラ エラー:error C2668: ambiguous call to overloaded function

次の理由により、どちらも解決する方法がわかりません。

1. これはconst pointerであるため、何らかの方法で shared_from_this と接続されていると思います。しかし、const_cast なしでこの状況を処理する方法がわかりません。
2. 関数がさまざまな種類の弱いポインターによってオーバーロードされる可能性があるかどうかはわかりません。

ビルド環境: MSVS 2013 Express

助けてください。ありがとうございました

循環性を避けるためshared_ptrに、 s と s で構成されるオブジェクト構造があります。シリアル化時にオブジェクト追跡を介して逆シリアル化するときに、共有ポインターと弱いポインターを復元する必要があるため、生のポインターは使用できません。オブジェクトのライフタイム パターンは複雑ですが (パーティクル シミュレーション)、完全に予測可能です。を使用するときはいつでも、ポインタがまだ有効であると確信しています。通常、私は非常に短い時間だけオブジェクトを必要とするので使用します。weak_ptrboost::serializationweak_ptr::lock()lock().get()

現在は、lock().get()共有カウントをインクリメントし ( でlock())、その後すぐにデクリメントするため、パフォーマンスに影響があります (一時的なshared_ptrものは破棄されます)。

2002 年のこのboost.devel の投稿weak_ptrによると、開発中に、生のポインタに直接アクセスする機能が ( unsafe_getorと名付けられてleak) 検討されましたが、実際の実装には至りませんでした。これがないと、プログラマは特定の条件下で次善のインターフェイスを使用することになります。

ここで、問題はunsafe_get/をエミュレートする方法ですleak。つまり、プログラマーのリスクで無効な から生のポインターを取得し、weak_ptrデータの読み取りのみ (書き込みではなく) を行う方法です。内部の生のポインターのオフセットを見つけるなどのトリックがshared_ptr仕事をするだろうと想像できます。

私は を使用してboost::shared_ptrいますが、このソリューションは c++11 でも機能する可能性がstd::shared_ptrあります。

例えば：

そのような機能は可能ですか？

ユースケース: クラスのコンストラクターはstd::weak_ptr<Foo>依存関係として受け取ります。期限切れのオブジェクトを渡すことは問題ありませんが (特定のワークフローで発生する可能性があります)、null を渡すことは、プログラマーが何かを忘れていることを意味します。コンストラクターのパラメーター検証の一環として、これをテストしたいと思います。

shared_ptr が参照されている weak_ptrs の数を調べる方法はありますか?

unique()/use_count() は shared_ptrs を見つけるために使用できますが、参照元の weak_ptrs を見つけるための同様の構造があります。

参照しているweak_ptrがない場合にのみ、shared_ptrが保持するリソースを解放したい。したがって、将来、このweak_ptrからshared_ptrを作成しようとしても、nullptrになってはいけません。

これは現在 C++11 で可能ですか?

オブジェクトの状態をキャプチャするラムダの有効期間について何も知らない場合があります (たとえば、オブジェクトから返す、サブスクライブ解除できないコールバックとして登録するなど)。呼び出し時にラムダが既に破棄されたオブジェクトにアクセスしないようにする方法は?

このプログラムは、偶然にも「OK」( http://ideone.com/Srp7RC )の代わりに「WRONG」を出力します(2番目のFooオブジェクトに同じメモリを再利用したようです)。とにかく、これは間違ったプログラムです。を実行すると、最初Fooのオブジェクトはすでに死んでいますf。