問題タブ [weak-ptr]

関連するいくつかのオブジェクト タイプへの参照を公開するライブラリを作成しました。これらのオブジェクトはすべて、ライブラリによって内部的に管理されているライフタイムを持っています。boost::shared_ptr

ライブラリのユーザーは、ライブラリの性質上、公開されたオブジェクトの有効期間を知ることもできます。そのため、これらのオブジェクトへのポインターを格納したり、参照を保持したりできます。彼らがこれを行い、それらのオブジェクトがいつ有効でなくなるかを知ることは合理的です。

しかし、ユーザーに合理的なことを強制することに罪悪感を覚えます。

weak_ptrライブラリが をそのオブジェクトに公開することは許容されますか? 他のライブラリはこれを行っていますか?

アプリでのこのライブラリの使用法をプロファイリングしたところ、weak_ptr排他的に公開するにはあまりにもミッション クリティカルであることがわかりました。

一致する API 関数で参照またはweak_ptr を公開するか、任意のオブジェクトweak_ptrをそれ自体に公開できるようにする方が賢明でしょうか?

アプリケーション全体で Boost/shared_ptr ポインターを使用しています。オブジェクトへの最後の参照が解放されると、shared_ptr がオブジェクトを削除します。アプリケーション内のオブジェクトは、オブザーバー/サブスクライバー パターンと同様に、アプリケーションの中央の場所でイベントをサブスクライブします。

オブジェクト デストラクタでは、オブジェクトはサブスクリプションのリストから自身をサブスクライブ解除します。サブスクリプションのリストは基本的に単なるlist<weak_ptr<MyObject> >. 私がやりたいことは、これに似たものです：

ここでの問題は、デストラクタで shared_from_this を呼び出すことができないため、上記のコードで例外がスローされることです。

私の古い実装では、サブスクリプション リストは単なるポインターのリストでしたが、それは機能していました。しかし、代わりにweak_ptr参照を使用して、手動のメモリ管理によってメモリを台無しにするリスクを減らしたいと考えています。

オブジェクトの削除は shared_ptr に依存しているため、Unsubscribe を論理的に呼び出すことができる場所がコード内に 1 か所もありません。

この状況で何をすべきかについてのアイデアはありますか？

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

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

weak_ptrこれとは別に、に変換したい場合はどうすればよいですかshared_ptr。ロックをオンにweak_ptrして作成すると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独占的に使用しています。ただし、この場合、ツリー内の子はその親にアクセスする必要があります（たとえば、マップ上の存在はマップデータにアクセスできる必要があります-親のデータをエルゴします。

もちろん、所有する方向は、マップがその存在を所有することであるため、それらへの共有ポインターを保持します。ただし、存在内からマップデータにアクセスするには、親へのポインターが必要です。スマートポインターの方法は、参照を使用することweak_ptrです。

ただし、aのロックweak_ptrはコストのかかる操作であると読んだことがありますが、これはもう当てはまらないかもしれませんが、weak_ptrが頻繁にロックされることを考えると、この設計のパフォーマンスが低下するのではないかと心配しています。

したがって、質問：

weak_ptrをロックするとパフォーマンスが低下しますか？それはどれほど重要ですか？

boost::shared_ptrカスタム削除機能が添付されています。これをに変換するweak_ptrと、削除者情報が失われますか？shared_ptrはいの場合、メソッドから取得した-sに同じ削除プログラムを再アタッチするにはどうすればよいweak_ptr::lock()ですか？

私が実装している機能は、weak_ptrあるタイプの生きているインスタンスを指す-sのコンテナーです。削除するオブジェクトのコンテナエントリを削除するには、カスタム削除機能が必要です。

オブジェクトがまだ構築されていないため、クラスのコンストラクターからshared_from_this（）を呼び出してshared_ptrを取得することはできないことを理解しています。ただし、コンストラクターからオブジェクトへのweak_ptrを取得することは可能ですか？「weak_from_raw（）」メソッドについて議論しているいくつかのブーストフォーラムの投稿は、それが可能かもしれないことを示唆しています。

編集：weak_from_rawを議論するブーストフォームhttp://lists.boost.org/boost-users/2010/08/61541.php

std ::weak_ptrのoperator<に関する説明を読んだ後、std::weak_ptrの制御ブロックを使用するようにstd::hashを定義しても機能しない理由がわかりません。また、これが標準化委員会によって無視されたとは信じられません。誰かがそのトピックに関連する議論を読んだことがありますか？

編集：演算子に関するディスカッション<std :: weak_ptr http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1590.html

私はこのようなものを持っています:

今度はアプリケーションを変更して、boost shared_ptr と weak_ptr を使用し、食品インスタンスを 1 か所で削除できるようにします。次のようになります。

しかし問題は、dynamic_cast が weak_ptr で動作しないように見えることです

オブジェクトが指すオブジェクトが派生型であることがわかっている場合、 aweak_ptr<Fruit>からa を取得するにはどうすればよいですか?weak_ptr<Food>

スコット・マイヤーズの「EffectiveC++」の本を読んでいます。tr1::shared_ptr組み込みのポインタがあり、そのように動作することが言及されましたが、それらはオブジェクトを指す tr1::weak_ptrポインタの数を追跡します。tr1::shared_ptrs

これは、参照カウントとして知られています。これは、非循環データ構造でのリソースリークの防止に役立ちますが、サイクルが形成されるようなオブジェクトが2つ以上含まれtr1::shared_ptrsている場合、サイクルへのすべての外部ポインタが破棄された場合でも、サイクルは互いの参照カウントをゼロより上に保つ可能性があります。

それがtr1::weak_ptrs入ってくるところです。

私の質問は、循環データ構造が参照カウントをゼロより上にする方法です。C++プログラムの例をお願いします。問題はどのように解決されweak_ptrsますか？（繰り返しますが、例を挙げてください）。