30

言い換えれば、実装はどのようにカウントを追跡するのでしょうか?

shared_ptrキーがポインタのアドレスで、値が参照の数であるすべてのインスタンスからアクセスできる、マップのようなオブジェクトが維持されていますか? を実装する必要がある場合shared_ptr、これが最初に頭に浮かんだアイデアです。

これらの参照カウント スマート ポインターの場合、メモリ リークの可能性はありますか? もしそうなら、どうすればそれらを避けることができますか?

4

7 に答える 7

2

多くの回答は、参照カウントの格納方法 (同じネイティブ ポインターを保持するすべての shared_ptr の共有メモリに格納されます) に対処していますが、ほとんどの場合、リークの問題を回避しています。

参照カウント ポインターでメモリをリークする最も簡単な方法は、サイクルを作成することです。例として、すべてのポインタが少なくとも 2 つの要素を持つ shared_ptr である双方向リンク リストは、削除されないことが保証されています。外部ポインタが解放されても、内部ポインタは引き続きカウントされ、参照カウントは 0 に達しません。つまり、少なくとも、最も単純な実装ではそうです。

サイクルの問題に対する最も簡単な解決策は、オブジェクトの所有権を共有しない弱いポインターと shared_ptr (参照カウント ポインター) を混在させることです。

共有ポインターは、リソース (ポインター) と追加の reference_count 情報の両方を共有します。ウィーク ポインターを使用すると、参照カウントが 2 倍になります。つまり、共有ポインター参照カウントとウィーク ポインター参照カウントがあります。リソースは、共有ポインターのカウントが 0 になるたびに解放されますが、reference_count 情報は、最後のウィーク ポインターが解放されるまで存続します。

二重リンク リストでは、外部参照は shared_ptr に保持されますが、内部リンクは単なる weak_ptr です。外部参照 (shared_ptr) がない場合は常に、リストの要素が解放され、弱参照が削除されます。最後に、すべての弱い参照が削除され、各リソースへの最後の弱いポインターが reference_count 情報を解放します。

上記のテキストよりも混乱が少ないようです...後でもう一度試します。

于 2009-04-07T13:43:51.263 に答える