発生する傾向があるのは、アイテムが純粋に管理されたリソースを持っている場合、 dispose を呼び出すことは必ずしも必要ではありませんが、破棄が決定論的になるため、強くお勧めします。これらの管理対象リソース自体が GC の対象となる可能性が高いため、(技術的な意味で) 常に必要とは限りません。または、実際にはデフォルトで破棄するものがなく、拡張ポイントであるためです。
管理されていないリソースの場合、Disposeパターンは、GC で呼び出されるfinalizerの実装を推奨しています。型がファイナライザーを実装せず、dispose が呼び出されない場合、リソースが未処理のままになる可能性があります(まあ、非常に可能性が高いです)。ファイナライザーは、ランタイムが提供する最後のチャンスであり、時間制限もあります。
GC またはマネージ メモリの再利用を決定論的にしないことに注意してください。破棄はC++ からではありません。 delete
廃棄されたアイテムは、実際に回収されるまでにはかなりの時間がかかる可能性があります。ただし、管理された世界では、決定論的なコレクションは気にせず、リソースの管理、つまり廃棄のみを行います。
とは言うものの、私は常に Dispose を呼び出すか、型が使い捨ての場合はステートメントを使用するようにusing
しています。
public void Show()
{
using (var f = new Form1())
{
f.ShowDialog();
} // Disposal, even on exceptions or nested return statements, occurs here.
}
アップデート:
Servy との話し合いの結果、この点を可能な限り処分するという私のアドバイスの背後にある理由として表明しなければならないと感じています. の場合、MemoryStream
明らかに使い捨てタイプですが、実際には現在何も処分していません。
ただし、これに依存することは、 の実装に依存することになりMemoryStream
ます。MemoryStream
これが管理されていないリソースを含むように変更された場合、これは、処分するものが何もないことに依存することが問題になることを意味します。
可能であれば ( の場合のように)、公的な契約IDisposable
に頼ることを好みます。この場合、コントラクトに反する作業を行うということは、基になる実装の変更から保護されていることを意味します。