私は数年前からWPFを使用してきましたが、マネージドコード以外の経験はありません。私はwin32 interopをたくさん使っているアプリを書くようになりました。私はメモリが漏れているのか、一般的に私が知らなかった何か愚かなことをしているのか疑問に思い始めました。マネージコードでのwin32の使用
マネージコード内でwin32呼び出しを使用しているときのヒント/ヒント/トリックはありますか? 私は主にメモリ/ガベージコレクションに興味がありますが、その他のヒントは大歓迎です!
私は数年前からWPFを使用してきましたが、マネージドコード以外の経験はありません。私はwin32 interopをたくさん使っているアプリを書くようになりました。私はメモリが漏れているのか、一般的に私が知らなかった何か愚かなことをしているのか疑問に思い始めました。マネージコードでのwin32の使用
マネージコード内でwin32呼び出しを使用しているときのヒント/ヒント/トリックはありますか? 私は主にメモリ/ガベージコレクションに興味がありますが、その他のヒントは大歓迎です!
問題がありません。割り当てたすべてのリソースを解放します(ただし、作成した呼び出しがリソースを引き継ぎ、所有権から解放されていることがドキュメンテーションに示されている場合を除く)。 GCはまったく入りません。
ヒントとして、System.Runtime.InteropServices.SafeHandle
は、Win32でRAII形式のハンドルを使用する在庫ヘルパークラスです。
Win32で割り当てるほとんどのリソースは、割り当てAPIのMSDNページに記載されている正しいAPI呼び出しで割り当て解除する必要があります。
これは完全に手動のプロセスです。ガーベジコレクションはこれをまったくサポートしていませんが、SafeHandleまたは(最後の手段)ファイナライザを使用できます。
少なくとも、割り振るリソースの周りにはIDisposable
ラッパークラスを使用してください。場合によっては、これらはWindowsフォームに既に存在します。
Perfmonまたはタスクマネージャを使用して、プロセスで開いているハンドルの数を監視できます。
win32 interopの主な問題は、(明らかに)Linux/Mac OSの非互換性です(Win32ライブラリへのP/Invokesがある場合、Monoはまだ手助けできません)。
それ以外は、私は何の問題も認識していません。もちろん、あなた自身が呼び出す関数がメモリを漏らさない限り。
GetLastErrorに電話をかけて、なぜwin32呼び出しが失敗したのかを判断する際には注意が必要です。 Thisページに詳しい説明があります。