言い換えれば、実装はどのようにカウントを追跡するのでしょうか?
shared_ptr
キーがポインタのアドレスで、値が参照の数であるすべてのインスタンスからアクセスできる、マップのようなオブジェクトが維持されていますか? を実装する必要がある場合shared_ptr
、これが最初に頭に浮かんだアイデアです。
これらの参照カウント スマート ポインターの場合、メモリ リークの可能性はありますか? もしそうなら、どうすればそれらを避けることができますか?
言い換えれば、実装はどのようにカウントを追跡するのでしょうか?
shared_ptr
キーがポインタのアドレスで、値が参照の数であるすべてのインスタンスからアクセスできる、マップのようなオブジェクトが維持されていますか? を実装する必要がある場合shared_ptr
、これが最初に頭に浮かんだアイデアです。
これらの参照カウント スマート ポインターの場合、メモリ リークの可能性はありますか? もしそうなら、どうすればそれらを避けることができますか?
多くの回答は、参照カウントの格納方法 (同じネイティブ ポインターを保持するすべての shared_ptr の共有メモリに格納されます) に対処していますが、ほとんどの場合、リークの問題を回避しています。
参照カウント ポインターでメモリをリークする最も簡単な方法は、サイクルを作成することです。例として、すべてのポインタが少なくとも 2 つの要素を持つ shared_ptr である双方向リンク リストは、削除されないことが保証されています。外部ポインタが解放されても、内部ポインタは引き続きカウントされ、参照カウントは 0 に達しません。つまり、少なくとも、最も単純な実装ではそうです。
サイクルの問題に対する最も簡単な解決策は、オブジェクトの所有権を共有しない弱いポインターと shared_ptr (参照カウント ポインター) を混在させることです。
共有ポインターは、リソース (ポインター) と追加の reference_count 情報の両方を共有します。ウィーク ポインターを使用すると、参照カウントが 2 倍になります。つまり、共有ポインター参照カウントとウィーク ポインター参照カウントがあります。リソースは、共有ポインターのカウントが 0 になるたびに解放されますが、reference_count 情報は、最後のウィーク ポインターが解放されるまで存続します。
二重リンク リストでは、外部参照は shared_ptr に保持されますが、内部リンクは単なる weak_ptr です。外部参照 (shared_ptr) がない場合は常に、リストの要素が解放され、弱参照が削除されます。最後に、すべての弱い参照が削除され、各リソースへの最後の弱いポインターが reference_count 情報を解放します。
上記のテキストよりも混乱が少ないようです...後でもう一度試します。