問題タブ [smart-pointers]

デザインの質問について意見が欲しかっただけです。他のオブジェクトを所有していない C++ クラスがある場合、これを実現するためにスマート ポインターを使用しますか?

'Owned' オブジェクトは、オブジェクトの存続期間を通じて変更される可能性があるため、値によって格納することはできません。

私の見解では、一方では、オブジェクトが所有されていることを明確にし、その削除を確実にしますが、反対に、通常のポインターを持っていて、デストラクタでそれを削除することは簡単にできます。これはやり過ぎですか？

フォローアップ:すべての回答に感謝したいと思います。オブジェクト全体がコピーされたときに他のオブジェクトに NULL ポインタを残す auto_ptr について注意していただきありがとうございます。私は auto_ptr を広範囲に使用しましたが、まだ考えていませんでした。私は基本的にすべてのクラスを boost::noncopyable にしています。また、例外でのメモリ リークに関する情報もありがとうございます。とにかく、コンストラクターで例外を引き起こす可能性のあるものを書かないようにしています-それを行うためのより良い方法があります-したがって、それは問題にはなりません。

ただ、別の質問がありました。この質問をしたときに私が欲しかったのは、誰かが実際にこれを行ったかどうかを知ることでした。皆さんは理論的には良い考えだと述べているようですが、実際に行ったとは誰も言っていません。これは私を驚かせます！確かに、あるオブジェクトが別のオブジェクトへのポインターを所有するというのは新しいアイデアではありません。どうしたの？

私はさまざまなスマートポインターの実装を評価してきましたが（うわー、そこにはたくさんあります）、それらのほとんどは2つの大まかな分類に分類できるようです。

1）このカテゴリは、参照されるオブジェクトの継承を使用して、参照カウントがあり、通常はup（）およびdown（）（またはそれらに相当するもの）が実装されているようにします。IE、スマートポインターを使用するには、ポイントしているオブジェクトは、ref実装が提供するクラスから継承する必要があります。

2）このカテゴリは、参照カウントを保持するためにセカンダリオブジェクトを使用します。たとえば、スマートポインターをオブジェクトに直接向ける代わりに、実際にはこのメタデータオブジェクトを指します...参照カウントとup（）およびdown（）の実装を持っている人（そして通常、ポインターのメカニズムを提供する人）スマートポインタが演算子->（）を適切に実装できるように、ポイントされている実際のオブジェクトを取得します。

これで、1には、カウントを参照するすべてのオブジェクトが共通の祖先から継承するように強制されるという欠点があります。これは、ソースコードを制御できないカウントオブジェクトを参照するためにこれを使用できないことを意味します。に。

2には、カウントが別のオブジェクトに格納されているため、既存の参照カウントオブジェクトへのポインタが参照に変換されているという状況が発生した場合、おそらくバグが発生するという問題があります（つまり、カウントが実際のオブジェクトでは、新しい参照がカウントを取得する方法はありません... ref to refコピーの構築または割り当ては、カウントオブジェクトを共有できるため問題ありませんが、ポインタから変換する必要がある場合は、完全にホースで固定されています）..。

さて、私が理解しているように、boost :: shared_pointerはメカニズム2、またはそのようなものを使用しています...とはいえ、私は自分の決心を完全に決めることはできません。私はこれまで本番コードでメカニズム1のみを使用しました...誰かが両方のスタイルの経験がありますか？または、おそらくこれらの両方よりも優れた別の方法がありますか？

shared_ptr<Type> t(makeSomething(), mem_fun(&Type::deleteMe)) へのポインタを必要とするCスタイルの関数を呼び出す必要があるようなものがありますType。からどうやって入手するのshared_ptr？

単純なパブリッシュ/サブスクライブパターンを実装したいと思います。

単一のパブリッシャーは、そのサブスクライバーにトークン（オブジェクトへのポインター）を公開します。パブリッシャーとサブスクライバーはすべて独立したスレッドです。サブスクライバーがトークンを処理している間、パブリッシャーがトークンをサブスクライバーに配布し続けることができるように、各サブスクライバーにスレッドセーフキューを追加する予定です。

ご覧のとおり、これはすべてのサブスクライバーが実際に同じポインターを共有していることを意味します（注：サブスクライバーはとにかくポイントされたオブジェクトを変更できないため、問題はありません）。共有ポインターがどのサブスクライバーによっても使用されなくなったら、最後のサブスクライバースレッドが使用された後、ポインターがそれ自体を自動削除できると非常に便利です。

これはスマートポインタを使用するのに適した場所ですか？もしそうなら、私はどのスマートポインタを使うべきですか？

私はMSVC2008を使用してWindowsで開発し、Intel TBB、Boost、およびQtを使用しています。

次の一連のポインターの違いは何ですか? 本番コードで各ポインターを使用する場合、いつ使用しますか?

例をいただければ幸いです。

1. scoped_ptr

2. shared_ptr

3. weak_ptr

4. intrusive_ptr

プロダクションコードでブーストを使用していますか?

だから私はこのライブラリコードを持っています、見てください...

そして私のクライアントコードでは...

私がこだわっているのは例外安全性です。現状では、Objコンストラクターのいずれかがスローされるか、Thingコンストラクターがスローされると、既にベクター内にあるObjsがリークします。ベクターは多態的に使用されているため、Objsへのポインターを含める必要があります。また、例外を処理する必要があります。これは、例外を認識しない古いコードベースから呼び出されているためです。

私が見ているように、私のオプションは次のとおりです。

1. クライアントコードを巨大なtryブロックでラップし、catchブロックのベクトルをクリーンアップします。
2. すべての割り当ての周りにtryブロックを配置し、そのcatchブロックは共通のクリーンアップ関数を呼び出します。
3. 私がまだ考えていないいくつかの巧妙なRAIIベースのアイデア。
4. パント。現実的には、コンストラクターがスローすると、とにかくアプリケーションが炎上しそうになりますが、これをより適切に処理したいと思います。

インターフェイスオブジェクトへの（スマートではない）ポインターを持つクラス（pInterfaceと呼びましょう）があり、そのインターフェイスへのアクセスも必要とするネストされたクラスを構築しています。次のように、インターフェイスへのポインターをネストされたクラスのコンストラクターに渡すことで、これを回避します。

ただし、このポインターをネストされたクラスに格納する最良の方法がわかりません。私は使用できます：

あなたたちは何を提案しますか、そしてその理由は何ですか?

編集：明確にする必要があります-ネストされたクラスはインターフェイスオブジェクトのメソッドを呼び出す必要がありますが、それを作成（または「指している」オブジェクトを変更）しません。親クラスがそれを担当します。

これは些細なことですが、私はそれを見つけることができないようです（そのようなクラスが存在しない限り！）

スマートポインタのSTLクラス（またはクラスのセット）とは何ですか？

アップデート

回答ありがとうござい
ます。標準の実装がないことに驚いています。

私はこれを使用することになりました： http： //archive.gamedev.net/reference/articles/article1060.asp