問題タブ [shared-ptr]

pImpl イディオムを使用する場合、a のboost:shared_ptr代わりに aを使用することをお勧めしstd::auto_ptrます。ブーストバージョンはより例外に優しいと読んだことがありますか？

[編集] std::auto_ptr<> を使用することは常に安全ですか、それとも別のブースト スマート ポインターが必要な状況がありますか?

を操作する必要がある関数がある場合、その関数へshared_ptrの参照を渡す方が効率的ではないでしょうか (shared_ptrオブジェクトのコピーを避けるため)。考えられる悪い副作用は何ですか? 次の 2 つのケースが考えられます。

1) 関数内で、次のように引数のコピーが作成されます。

2) 関数内では、次のように引数のみが使用されます。

どちらの場合も、参照ではboost::shared_ptr<foo>なく値で渡す正当な理由がわかりません。値渡しは、コピーのために参照カウントを「一時的に」インクリメントするだけで、関数スコープを終了するときにデクリメントします。私は何かを見落としていますか？

明確にするために、いくつかの回答を読んだ後：私は時期尚早の最適化の懸念に完全に同意し、常に最初にプロファイルしてからホットスポットで作業しようとします. 私の質問は、純粋に技術的なコードの観点からのものでした。

いくつかの異なるクライアントに提供する C++ ライブラリがあります。最近、パブリック インターフェイスで生のポインターを使用することから、代わりに boost::sharedptr を使用するように切り替えました。ご想像のとおり、これにより、クライアントは誰が何をいつ削除する必要があるかを心配する必要がなくなるという点で、非常に大きなメリットがもたらされました。切り替えを行ったとき、私はそれが正しいことだと信じていましたが、公開インターフェイスにサードパーティのライブラリから何かを含める必要があることに悩まされていました。通常、そのようなことはできれば避けま​​す。私は、boost は事実上 C++ 言語の一部であり、私たちのユース ケースでは、クライアント コードとライブラリの両方がオブジェクトへのポインターを保持する必要があることを合理化しました。しかし最近、クライアントの 1 人から、インターフェイスでニュートラル スマート ポインター クラスを使用するように切り替えることができるかどうか尋ねられました。私たちのライブラリは基本的に特定のバージョンのブーストを強制しているためです。では、どうするのが最善策なのか、今考えています。私はそれについて少し考え、実際のブースト スマート ポインターを単に保持する単純なスマート ポインター クラスを作成することについて疑問に思いました。しかし、クライアントはすぐにそれらの 1 つを自分たちのフレーバーの boost::sharedptr に詰め込み、3 つの共有ポインターの深さになります。これは問題になる場合もあれば、そうでない場合もあります。とにかく、この問題を解決する最善の方法についてコミュニティから意見を聞きたいです。私はそれについて少し考え、実際のブースト スマート ポインターを単に保持する単純なスマート ポインター クラスを作成することについて疑問に思いました。しかし、クライアントはすぐにそれらの 1 つを自分たちのフレーバーの boost::sharedptr に詰め込み、3 つの共有ポインターの深さになります。これは問題になる場合もあれば、そうでない場合もあります。とにかく、この問題を解決する最善の方法についてコミュニティから意見を聞きたいです。私はそれについて少し考え、実際のブースト スマート ポインターを単に保持する単純なスマート ポインター クラスを作成することについて疑問に思いました。しかし、クライアントはすぐにそれらの 1 つを自分たちのフレーバーの boost::sharedptr に詰め込み、3 つの共有ポインターの深さになります。これは問題になる場合もあれば、そうでない場合もあります。とにかく、この問題を解決する最善の方法についてコミュニティから意見を聞きたいです。

編集: 私はもともと所有権の譲渡を言いましたが、API 境界の両側のコードがオブジェクトへのポインターを保持する必要があることを指定する必要がありました。

私は自分のコードでboost::scoped_ptrを多用していますが、それは素晴らしいことですが、現在、どこでもshared_ptrを使用するソフトウェアを使用しており、何かが足りないのではないかと思っています。

Shared_ptrは、異なるスレッドが同じデータにアクセスする予定であり、スレッドが終了する順序がわからない場合にのみ役立ちます（shared_ptrを使用すると、最後のスレッドが終了するまでオブジェクトが存在することが保証されます）。

他のユースケースはありますか？

あるモジュールで何かを新規作成し、別のモジュールで削除すると、VC++ で問題が発生することがよくあります。異なるランタイムの問題。静的にリンクされたランタイムおよび/または動的にリンクされたバージョン管理の不一致を持つモジュールを混在させると、正しく思い出せば問題が発生する可能性があります。

しかし、モジュール間で VC++ 2008 の std::tr1::shared_ptr を使用しても安全ですか?

shared_ptr が何であるかさえ知っているランタイムのバージョンは 1 つしかないため、静的リンクが唯一の危険です (今のところ...)。ブーストのバージョンの shared_ptr はこのように安全に使用できると読んだことがあると思いましたが、レドモンドのバージョンを使用しています...

割り当てモジュールでオブジェクトを解放する特別な呼び出しを回避しようとしています。（または、クラス自体の「これを削除」のようなもの）。これが少しハッキリしていると思われる場合は、これを単体テストに使用しています。既存の C++ コードの単体テストを試みたことがある場合は、どのように創造性を発揮する必要があるかを理解できます。私のメモリはEXEによって割り当てられますが、最終的にはDLLで解放されます(参照カウントが私が思うように機能する場合)。

などのスマート ポインターを使用する C++ プロジェクトでboost::shared_ptr、" " の使用に関する優れた設計哲学は何thisですか?

次のことを考慮してください。

• スマート ポインターに含まれる生のポインターを後で使用するために保存するのは危険です。オブジェクトの削除の制御をあきらめ、スマート ポインターが適切なタイミングでそれを実行することを信頼します。

• 非静的クラス メンバーは、本質的にthisポインターを使用します。これは生のポインターであり、変更することはできません。

別の変数に保存thisしたり、後で保存したり、コールバックでバインドしたりする可能性のある別の関数に渡すと、誰かがクラスへの共有ポインターを作成することを決定したときに導入されるバグが作成されます。

thisそれを考えると、ポインタを明示的に使用することが適切なのはいつですか? これに関連するバグを防ぐことができる設計パラダイムはありますか?

過去 2 年間、プロジェクトでスマート ポインター (正確には boost::shared_ptr) を広く使用してきました。私はそれらの利点を理解し、高く評価しており、一般的にそれらをとても気に入っています. しかし、それらを使用すればするほど、プログラミング言語で気に入っているように見えるメモリ管理と RAII に関する C++ の決定論的な動作が恋しくなります。スマート ポインターは、メモリ管理のプロセスを簡素化し、とりわけ自動ガベージ コレクションを提供しますが、問題は、一般的に自動ガベージ コレクションを使用し、スマート ポインターを具体的に使用すると、初期化 (非) 化の順序である程度の不確定性が導入されることです。この不確定性は、プログラマーからコントロールを奪い、最近気付いたように、API の設計と開発の仕事をします。

さらに詳しく説明すると、現在 API を開発しています。この API の一部では、特定のオブジェクトを他のオブジェクトの前に初期化または破棄する必要があります。別の言い方をすれば、初期化 (非) 化の順序が重要な場合があります。簡単な例として、System というクラスがあるとします。システムは、いくつかの基本的な機能 (この例ではロギング) を提供し、スマート ポインターを介して多数のサブシステムを保持します。

すでにおわかりのように、サブシステムはシステムのコンテキストでのみ意味があります。しかし、そのような設計のサブシステムは、その親システムよりも簡単に存続できます。

サブシステムを保持するために生のポインターを使用していた場合、システムがダウンしたときにサブシステムを破棄していたでしょう。もちろん、pSomeSubsystem はダングリング ポインターになります。

クライアント プログラマを保護するのは API 設計者の仕事ではありませんが、API を正しく使いやすく、間違って使いにくくすることは良い考えです。だから私はあなたたちに尋ねています。どう思いますか？この問題をどのように緩和すればよいですか? そのようなシステムをどのように設計しますか?

前もって感謝します、ジョシュ

完全にスレッドセーフなshared_ptr実装を知っている人はいますか? たとえば、ブーストの実装はshared_ptr、ターゲット (refcounting) に対してスレッドセーフであり、同時shared_ptrインスタンス読み取りに対しても安全ですが、書き込みまたは読み取り/書き込みに対しては安全ではありません。

( Boost docsの例 3、4、および 5 を参照してください)。

shared_ptrインスタンスに対して完全にスレッドセーフな shared_ptr 実装はありますか?

奇妙なブースト ドキュメントは次のように述べています。

shared_ptr オブジェクトは、組み込み型と同じレベルのスレッド セーフを提供します。

しかし、通常のポインター (組み込み型) を と比較すると、通常のポインターsmart_ptrの同時書き込みはスレッドセーフですが、 への同時書き込みはそうでsmart_ptrはありません。

編集: x86 アーキテクチャでのロックフリーの実装を意味します。

EDIT2: このようなスマート ポインターの使用例は、現在の作業項目でグローバル shared_ptr を更新する多数のワーカー スレッドと、作業項目のランダム サンプルを取得するモニター スレッドがある場合です。shared-ptr は、別の作業項目ポインターが割り当てられるまで (それによって前の作業項目を破棄する) 作業項目を所有します。モニターは、ワークアイテムを独自の shared-ptr に割り当てることにより、ワークアイテムの所有権を取得します (それにより、ワークアイテムが破棄されるのを防ぎます)。XCHG と手動削除で実行できますが、shared-ptr で実行できると便利です。

もう 1 つの例は、グローバル shared-ptr が「プロセッサ」を保持し、あるスレッドによって割り当てられ、他のスレッドによって使用される場合です。「ユーザー」スレッドは、プロセッサの shard-ptr が NULL であることを確認すると、代替ロジックを使用して処理を行います。NULL でない場合は、プロセッサを独自の shared-ptr に割り当てることで、プロセッサが破壊されるのを防ぎます。

私はほとんどのOOP理論をしっかりと理解していますが、私を非常に混乱させているのは仮想デストラクタです。

デストラクタは、何があっても、チェーン内のすべてのオブジェクトに対して常に呼び出されると思いました。

いつそれらを仮想化するつもりですか、またその理由は何ですか?