1

私は現在、ブースト共有ポインタと弱いポインタ、さらにロキスマート ポインタとストロング ポインタなどの最も人気のあるスマート Ptr 実装を検討しています。これは、自分自身を実装したいからであり、理解していることから、ロキ ストロング ポインタは安全ではないように見えますが、むしろ私は理解が間違っているので、安全かどうか議論したいと思います。安全ではないと私が考える理由は、私が知る限り、弱いポインター (つまり、false が弱いことを示す StrongPtr) を十分に注意して処理しないためです。

たとえば、逆参照関数:

PointerType operator -> ()
{
KP::OnDereference( GetPointer() ); //this only asserts by default as far as i know
//could be invalidated right here
return GetPointer();
}

マルチスレッド環境では、弱いポインターはいつでも無効化される可能性があるため、この関数は無効化された Ptr を返す可能性があります。

私の理解では、逆参照しているptrのstrongPtrインスタンスを作成して、途中で無効にならないようにする必要があります。それが、最初に shared_ptr インスタンスを作成せずにboostでweak_ptrを逆参照できない理由でもあると思います。Lokis StrongPtr Constructor は、私が思うのと同じ問題に苦しんでいます。

これは問題ですか、それとも src の読み方が間違っていますか?

4

2 に答える 2

3

の使用に関しては、空のインスタンスで使用するassertのはプログラミング エラーです。つまり、インスタンスを逆参照する前に、インスタンスが空でないことを確認するのは呼び出し元の責任です。なぜ以上のものが必要なのですか？とはいえ、他の動作の方が より適切であると思われる場合は、まさにそれがポリシーの目的です。operator->StrongPtr<>StrongPtr<>assertassert

これは、事前条件と事後条件の基本的な違いです。これは、主題に関する長いが非常に優れたスレッドです: comp.lang.c++.moderated: Exceptions。特に、D. Abrahams の投稿を読んでください。彼は、私が理解している事実として述べていることを詳細に説明しています。;-]

のスレッド セーフに関しては、StrongPtr<>ほとんどの Loki は深刻なスレッド セーフの問題よりも前から存在していたのではないかと思います。一方、boost::shared_ptr<>スレッドセーフであることstd::shared_ptr<>が明示的に保証されているため、それらの実装は「より良い」（はるかに複雑ではありますが）研究の基礎になると確信しています.

于 2011-05-03T10:00:20.223 に答える
0

注意深く読んだ後、私は理論的根拠を見たと思います。

StrongPtrStrongオブジェクトは、とWeak参照の両方を表すという点で二重です。

のメカニズムはassert、バージョンでうまく機能しStrongます。バージョンでは、Weak参照されたオブジェクトが十分に存続することを保証するのは呼び出し元の責任です。これは、次のいずれかで実現できます。

  • Strongバージョンがあることがわかっている場合は、自動的に
  • Strongインスタンスを作成して手動で

利点std::shared_ptrは、アイテムが使用後も存続することがすでにわかっている場合に、新しいオブジェクトを作成することを回避できることです。これは議論の余地のある設計上の決定ですが、専門家にとってはうまく機能します (Alexandrescu は間違いなくそうです)。通常のユーザー（私たち）を対象としていない可能性があり、Strongバージョンの取得を強制する方がはるかに優れていたはずです。

後知恵の恩恵を受けて批判する方が常に簡単だと主張することもできます. Loki、そのすべての偉大さのために、古いです。

于 2011-05-03T12:20:41.810 に答える