問題タブ [shared-ptr]

参照:同様の質問

以下のコードは明らかに危険です。問題は、*this への参照をどのように追跡するかということです。

私は答えを持っています（以下に投稿）。私はそれをstackoverflowに載せたいだけです（私が間違っている場合は誰もが私を修正できます.）

「The C++ Standard Library Extensions」の問題があります。

練習問題 6
セクション 2.4.2 で、同じポインターから 2 つの shared_ptr オブジェクトを作成してはならないと言いました。危険なのは、shared_ptr オブジェクトまたはその子孫の両方が最終的にリソースを削除しようとすることであり、通常はこれが問題を引き起こします。実際、気をつけていれば、これを行うことができます。特に便利ではありませんが、同じポインターから 2 つの shared_ptr オブジェクトを作成し、リソースを 1 回だけ削除するプログラムを作成してください。

以下は私の答えです：

しかし、それは良い解決策だとは思いません-コンストラクターを使用して解決したくないからです。誰かが私にもっと良いものをくれますか? thx、私の悪い英語を許してください。

次のコードで何が起こっているのかを理解しようとしています。object-c が object-b への shared_ptr を保持しているため、object-a が削除された場合、その shared_ptr メンバー変数 object-b はメモリに残りますか?

私はニューラル ネットワークを作成しており、各ニューロンの出力ニューロンの重み参照を保持するために hash_map を使用したいと考えていました。

boost::shared_ptr を stdext::hash_map のキーとして使用できないことに気付いたので、別の提案は何でしょうか? 回避策はありますか、または別のキーを使用するか、std::map に切り替える唯一のオプションですか? ありがとう！

エラーは次のとおりです。

shared_ptr 内部を認識し、格納された shared_ptr 要素の定期的なコピーを回避して、内部の弱いポインターをコピーするだけのコレクションが存在しますか?

これは暗黙のうちに、コンストラクタ/デストラクタの呼び出しが行われず、shared_ptrs の参照カウンターが操作されないことを意味します。

C++のアプリケーションでboost::shared_ptrを使用しています。メモリの問題は非常に深刻であり、アプリケーションは大量のメモリを消費します。

ただし、すべての新しいオブジェクトをshared_ptrに配置したため、アプリケーションが終了しても、メモリリークは検出できません。

std::vector<shared_ptr<> >リソースを保持しているプールのようなものが必要です。デバッグ時に、誰がshared_ptrを保持しているかを知るにはどうすればよいですか？

コードを1行ずつ確認するのは困難です。コードが多すぎます...

どうもありがとう！

と次の (で)の間boost::shared_ptrに違いはありますか?std::tr1::shared_ptrC++0xstd::shared_ptr

あるものから別のものへの移植にはオーバーヘッドがありますか、それとも基本的に同じですか?

ネットワークスレッドが実行するすべてのフレームの最後に出力オブジェクトが作成されるマルチスレッドフレームワークを実装しようとしています。これにより、別のスレッドがそのフレームの開始時に最新の「完了した出力」ポインターを取得できます。また、出力オブジェクト内に保存されているデータへの安全で完全な読み取り専用アクセスがあることを知っています。

これに対する私の（非常に初期の）アプローチには、主に次のコードブロックが含まれます。

NetworkHandler -

ClientNetworkHandler -

PyCruHandler -

基本的に、ClientNetworkHandler と PyCruHandler は別々のスレッドで独立して実行されます。PyCruHandler は m_latestNetworkOutput のコピーに対して実際には何もしません。何らかの方法でアクセスされる他のすべてのインスタンスをコメントアウトしましたが、まだ次の問題があります。

両方のスレッドが swap (または同等の operator=) を呼び出せるようにすると、最終的に (通常は実行から 2 秒以内ですが、数分かかることもあります)、オペレーターの新規またはアロケーターの削除のいずれかで次のエラーが発生します。選別：

「ヒープ: 解放された後に 2bab3dc で変更されたヒープ ブロック 2bab3b0 を解放する Windows がブレークポイントをトリガーしました。

これはヒープの破損が原因である可能性があり、これはバグを示しています...など."

私は初心者にすぎませんが、これは、shared_ptr オブジェクト間のスレッドセーフとタイミングに敏感なアクセスの問題に関するある種の問題を示しているようです。ただし、shared_ptr スレッド セーフのニュアンスの説明 (ここと他の場所の両方) に当惑するほど混乱してきました。参照カウントがスレッド セーフであることを示す読み取りがあるため、shared_ptrs をコピーしても安全です (ただし、その内部オブジェクト)。スレッド セーフにはなりません)、その他の読み物は、shared_ptr には有用なスレッド セーフが実質的に存在しないことを示しています。shared_ptrs のスレッド セーフに関するブースト ドキュメントを読みましたが、これが私のコードで問題になるかどうかはまだわかりませんでした。

私の質問は、ここにいる誰かが私がしていることの明らかな欠陥を見つけることができますか? 私の目標は、所有スレッドによってまだ保存されている最新の出力オブジェクトにアクセスできるようにすることです。その後、出力のすべてのユーザーがそれを処理するまで、そのオブジェクトは (所有スレッドが後の出力に移動した後でも) 削除されません。同じように。私の頭の中では、共有ポインターはこれに最適なように思えました...しかし、これに頭をぶつけて3時間後、私は疑問に思い始めています...

事前にどうもありがとうございました。これを誤って投稿した場合はお詫び申し上げます。ここに来るのは初めてで、プロトコルに関する限り、FAQ はかなりのんびりしているように見えました。

すべてのコードでの使用にほぼ移行しましたが、シングルトンクラスなど、boost::shared_ptr使用するいくつかの孤立したケースがまだあります。std::auto_ptr

これが行われなかったのには非常に正当な理由があると言われましたがshared_ptr、私の人生ではその理由がわかりません。それauto_ptrは最終的に次の標準で減価償却としてマークされることを知っているので、この実装をどのように/どのように置き換えることができるかを知りたいです。

auto_ptrまた、？の代わりに使用することを検討する理由は他にありshared_ptrますか？また、将来、shared_ptrに移行する際に問題が発生することはありますか？

編集：

1. したがって、「上記のコードで安全に置き換えることができますか」という答えでは、答えは「はい」です。ただし、パフォーマンスにわずかな影響を与えますauto_ptr。shared_ptr
2. auto_ptr最終的に減価償却としてマークされ、に移動したらstd::shared_ptr、コードを徹底的にテストして、さまざまな所有権のセマンティクスに準拠していることを確認する必要があります。

C++ の参照は、次の C コードを単純化できる便利な構造です。

に

共有ポインターは、メモリ管理を簡素化する C++ のもう 1 つの便利な機能です。ただし、参照によって引数を受け入れるshared_ptrような関数に aを渡す方法がわかりませんか?f(object& o)

オブジェクトが関数への参照によって渡されると、共有ポインタはインクリメントされますか?