「File と Font は、アンマネージド リソース (この場合はファイル ハンドルとデバイス コンテキスト) にアクセスするマネージド型の例です。他にも多くの種類のアンマネージド リソースとそれらをカプセル化するクラス ライブラリ型があります。そのような型はすべて、IDisposable インターフェイスを実装する必要があります。ルールとして、IDisposable オブジェクトを使用する場合は、using ステートメントで宣言してインスタンス化する必要があります。」-MSDN
USING ステートメントを使用する必要がある場合 (FILE や FONT などのアンマネージド リソースにアクセスするマネージド型) のリストはありますか?
を実装する型はIDisposable、 を使用する必要がありますusing。
更新(コメントに応じて):型usingのインスタンスを囲むIDisposable必要があります。これは、より大きなスコープでは必要ないと仮定します。
正しいアプローチは、型がインターフェイスを実装する場合は常にusingステートメントを使用するIDisposableことですが、規則の例外を知っています。
既知の例外:
Applicationメイン フォーム (クラスによって管理されるため、Windows フォーム アプリケーション)SystemPens.*、SystemBrushes.*(これらの静的インスタンスは内部的にキャッシュされます)Icons.*(これらの静的インスタンスは内部的にキャッシュされます)Registry.*(これらの静的インスタンスは内部的にキャッシュされます)AutoResetEvent、ManualResetEvent（本当は処分すべきですが、レース状態になる可能性があるので慎重に行います）既知の例外のリストは完全ではありません。
決定論的なクリーンアップが必要なリソースがあるとき、つまり、使い終わったらすぐに「破棄」できるようにしたいとき。
より詳細には、IDisposible インターフェースは主に、.net 言語に「delete」キーワードがないことを解決しようとします。CLR はガベージ コレクトされるため、オブジェクトのファイナライザー (デストラクター) がいつ実行されるかはわかりません。GC は、管理対象リソースを解放する前に、好きなだけ待機することができます。
ただし、多くの管理対象リソースは、基礎となる有限リソースをラップしています。割り当てと割り当て解除が必要なのはメモリだけではありません。前述のように、ファイル ハンドルは 1 つです。データベースは別のものを処理します - 無数の例があります。一貫性のないクリーンアップ イディオムの混乱を避けるために、IDisposible パターンを使用して、「有限のリソースを解放してください。私はそれらを使い果たしました」と言います。これはフレームワークに組み込まれているため、"using" を介して特別な言語サポートを取得し、Dispose メソッドの呼び出しを忘れないようにして、アンマネージ リソースを "リーク" させないようにします。
これは、すべてのIDisposible 実装者を using でラップする必要があるという意味ではありません。参照を保持していて、将来それらが必要になる場合は、基礎となるリソースの早期リリースを引き起こすため、それらをラップしないでください。Disposeは、オブジェクトの使用が終了したときにのみ呼び出します。したがって、使用中のスコープが終了した後で、使用が終了したことがわかっている場合にのみ、「使用中」にラップします。
したがって、当然のことながら、C++/CLI などの決定論的破壊を行う言語では、"using" は必要ありません。ヒープ以外の C++/CLI オブジェクトは、スコープ外になると Dispose メソッドが自動的に呼び出され、パターンがキャプチャしようとするデストラクタの動作を模倣します。
いいえ。MSDN の記事では、オブジェクトを使用するときにそれを採用することを検討する必要があると述べていIDisposableます。を実装するフレームワーク クラスはIDisposable多数あり、独自のクラスも多数定義することになるでしょう。
単純なルールは、「ガベージ コレクターがリソースを解放しようとする将来の未知の時点ではなく、使用後すぐに解放する必要があるリソースがあるときはいつでも」です。
基本的に、管理されていないか管理されているすべての限られたリソース。ファイル、ネットワーク ソケット、データベース接続、レジストリ ハンドルなど、無期限に放置してはならないもの。