問題タブ [weak-ptr]

newで作成されたオブジェクトへのポインタのベクトルがあります。複数のスレッドが、さまざまな get/set を使用して安全な方法でこのベクトルにアクセスします。ただし、スレッドがオブジェクトの 1 つを削除する場合があります。その場合、そのオブジェクトへの別のスレッドのポインターは無効になります。メソッドはポインタが有効かどうかをどのように知ることができますか? オプション 1 と 2 は、実際にはうまく機能しているようです。それらがどのようにスケーリングするかはわかりません。最善のアプローチは何ですか？ポータブル バージョン 3 はありますか?

機能するポインターの有効性の例のテスト:

1.ポインターの代わりに整数を使用します。ハッシュ (std::map) は、ポインターがまだ有効かどうかを確認します。パブリック メソッドは次のようになります。

2. shared_ptrのベクトルを用意します。各スレッドは、そのweak_ptrで lock() を呼び出そうとします。返された shared_ptr が null の場合、待機中に誰かが削除したことがわかります。パブリック メソッドは次のようになります。

3.プレーンな raw ポインターで null をテストしますか? これは可能ですか？

のを含むクラスがstd::setありboost::weak_ptr<T>ます。イテレータをコンテナに返す2つの関数begin（）とend（）があります。ただし、クライアントが変更できるようにしたくありませんT。が指しているものは編集可能であるため、単に返すだけでconst_iteratorは機能しません。Tboost::weak_ptr

私がやりたいのはにを返すことconst_iteratorですstd::set<boost::weak_ptr<T const> >。からのキャストはstd::set<boost::weak_ptr<T> >::const_iterator機能しません。私が望む振る舞いを得る方法はありますか？

使い方とを理解していweak_ptrますshared_ptr。shared_ptrオブジェクト内の参照の数を数えることで、どのように機能するかを理解しています。どのように機能しweak_ptrますか？私はブーストのソースコードを読んでみましたが、ブーストが使用するすべてのものを理解するのに十分な知識がありません。

ありがとう。

継承階層内のオブジェクトに std::shared_ptrs を使用しているロジックがあります。ある時点で、これらのオブジェクトを実際の型に応じて処理する必要があるため、二重ディスパッチを使用しています (つまり、基本クラスでメソッドを呼び出し、次に、実際の型を持つ別のオブジェクトのメソッドを呼び出します。例を参照してください)。 GoF の訪問者パターン)。

この時点で、オブジェクトへの参照を正しい型またはコピーで渡すことができます。いくつかの理由から、コピーは論外です。呼び出しは shared_ptr が存在するスコープより下のスコープで発生するため、参照は通常は問題ありません。したがって、この呼び出しが発生している間は破棄されません。ただし、一部のサブタイプでは、オブジェクトを STL コンテナーに格納する必要があるため、オブジェクトが破棄されないようにする必要があります。明らかに、裸のポインターまたは新しい shared_ptr はここでは機能しないため、これが呼び出された shared_ptr への参照を取得する必要があります。

現在、私は次のことを行っています。実際のコンストラクターではなく、名前付きコンストラクターを使用してオブジェクトを作成します。これにより、オブジェクト内に weak_ptr が設定され、オブジェクトを使用するための shared_ptr が提供されます。二重のコールバックが発生すると、weak_ptr から新しい shared_ptr を取得し、これをコンテナーに格納するので、オブジェクトは破棄されません。ただし、これにより、構築のロジックが非常に醜くなります。

これを行うより良い方法はありますか？

c++0x では、std::shared_ptr 用の std::static_pointer_cast がありますが、std::weak_ptr 用の同等のメソッドはありません。これは意図的なものですか、それとも見落としですか？見落としがある場合、適切な関数をどのように定義しますか?

一般的に、私は Google のスタイル ガイドに従います。これは、私が物事を見る方法とうまく一致していると感じています。また、ほぼ例外なく、boost::scoped_ptr を使用して、特定のオブジェクトの所有権を 1 人のマネージャーだけが持つようにしています。次に、裸のポインターを渡します。私のプロジェクトは、オブジェクトを使用するオブジェクトが破棄された後、そのオブジェクトのマネージャーが常に破棄されるように構造化されているという考えです。

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Smart_Pointers

これはすべて素晴らしいことですが、所有者を使用していたオブジェクトが削除される前に、所有者がたまたま削除されてしまうという厄介な小さなメモリストンプバグに噛まれました.

さて、みんなが私がこのパターンのばかだと飛び跳ねる前に、単に shared_ptr を使用しないのはなぜですか? など、未定義の所有者セマンティクスを持ちたくないという点を考慮してください。shared_ptr はこの特定のケースをキャッチできますが、システムのユーザーに間違ったメッセージを送信します。「誰がこれを所有しているのかわかりません。あなたかもしれません!」と書かれています。

私を助けたのは、スコープ付きポインターへの弱いポインターだったでしょう。実際には、スコープ付きポインターが破棄されると null になる弱参照のリストを持つスコープ付きポインター。これにより、単一所有権のセマンティクスが可能になりますが、使用中のオブジェクトに、私が遭遇した問題をキャッチする機会が与えられます。

したがって、scoped_ptr の追加の「weak_refs」ポインターと、weak_ptr の「next_weak_ptr」の追加ポインターを犠牲にして、きちんとした小さな単一所有者、複数ユーザー構造を作成します。

それはおそらく単なるデバッグ機能である可能性もあるため、「リリース」では、システム全体が通常のサイズの scoped_ptr と弱参照用の標準の単一ポインターに戻ります。

だから.....これのすべての後の私の質問は次のとおりです。

1. stl/boost に既にそのようなポインター/パターンがありませんか、それとも自分でロールする必要がありますか?
2. 私の単一所有権の目標をまだ満たしている、より良い方法はありますか?

乾杯、シェーン

以下はweak_ptrのコンストラクターの2つです：http： //msdn.microsoft.com/en-us/library/bb982126.aspx

実際のコード（からmemory）：

Q1：トップコピーコンストラクターがそこにあるのはなぜですか？下の方がすべてのケース（上の方を含む）を説明しているように見えます。それも呼ばれますか？そして、それらが含まれていなかった場合、一番下のものがその場所になりますか？

Q2：一番下の（テンプレート化された）コンストラクターの2番目の引数はどうなっていますか。SFINAEの側面は理解していると思いますが、なぜ余分な*が後にあるのかわかりません::type

私は STL を使用して MVP パターンを実装しようとしていますが、繰り返し参照するときに「サイクルを壊す」ために *shared_ptr* と *weak_ptr* を使用しました。

まだ 1 つの質問があります: thisポインターから shared_ptr を取得するにはどうすればよいですか? ブーストによって提案されたソリューションを見ましたが、それほど遠くないと心から思います。問題は、*weak_ptr* を設定する唯一の方法は、shared_ptr から行うことであり、それ自体に shared_ptr を持たないクラス内でこれを行う必要がある場合、それは困難になるということです。

したがって、ここでは基本的にビューがモデルを作成しますが、モデルはビューを参照して Observer パターンを実装する必要があります。問題は、モデルのweak_ptrビューポインターを設定できないため、行き詰まっていることです。

他の方法はありますか？:) これは、私がブースト担当者を信用していないと言っているようなものですが、そうではありません。実際、私の質問は、そもそもこの混乱に陥らずに MVP を実装する別の方法があるかどうかということです。

PS: MVP 監視コントローラー パターンを実装しようとしています。コード サンプルでは、​​i_presenter インターフェイスを除外しました。コンパイル エラーはさらに上にあります。パッシブ ビュー アプローチを試したとしても、同じでした。詳細については、ここでModel-View-Presenter Pattern を参照してください。

次のコードがあります。

このサンプルを開始すると、次のアサートが得られます: _BLOCK_TYPE_IS_VALID(pHead->nBloakUse)。

どうすればこれを回避できますか?

この問題を解決するために次のコードを使用しました。

しかし、もっと良い解決策があると思います。

怠惰な初期化パートナーの実装shared_ptrを知っている人はいますか? weak_ptrクラスの要件は次のとおりです。

• lazy_ptrコンストラクターの実装を必要とせずに、クライアントがオブジェクトを後で (もしあれば) 構築できるようにするクラス

• 3 つの可能な状態を持つweak_lazy_ptrクラス: まだ構築されていない ( にロックされないshared_ptr)、構築されている ( にロックされているshared_ptr)、および破棄されている ( にロックされていないshared_ptr)

少し前に、完全には機能しなかったいくつかのクラスを作成しました ( CVuの記事はこちらを参照) 。共有ポインターとウィーク ポインターを統合する代わりに使用するモデルの主な問題は次のとおりです。shared_ptrweak_ptr

1. すべてのオブジェクトが範囲外になると、他のクライアントがバージョンlazy_ptrを保持していても、弱い参照をロックできなくなりますshared_ptr

2. 異なるスレッドでのオブジェクトの構築は制御できません

これらの問題を調整するための他の試み、またはこの分野で進行中の作業へのポインタをいただければ幸いです。