アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
本当にバグの場合もあるけど (スコア:5, 参考になる)
はまった内容:
悪い例:
Form form = new HogeForm();
form.ShowDialog();
form.Dispose();
良い例:
Form form = new HogeForm();
form.ShowDialog();
form.Dispose();
form = null;
最後にnullを設定しないと、このフォームがガベージコレクトされず、
メモリリークします。なんだそれ。
マイクロソフトのサポートに問い合わせたところ、
マイクロソフト側でも現象を確認したそうで、
回答が「最後でnullを設定してね」でした。
マイクロソフトはバグとは言いませんでしたが、どう見てもバグですね。
メモリリークするよ~、あんたのコードが悪いんでしょ~、
なんとかしてよ~、とつつかれて大変でした。
Re:本当にバグの場合もあるけど (スコア:1)
まだDOSが当たり前だったころ、当然16ビット用のアプリなんですが、
スタック領域を8000hバイトと指定してMASMでアセンブルしたら、
なぜか符号拡張されてFFFF8000hバイトの確保に走り、メモリ不足のアセンブルエラーとなりました。
しょうがないので7C00hぐらいに減らして回避しましたが。
その2
VB 4.0のthreed.ocxは普通に使うだけでメモリリークする困ったやつなわけですが、
これを使ったアプリが長時間連続動作で落ちるという状態になりまして。まぁ当然なんですが。
開発元に連絡したところ、「それはMSのバグなんでうちは対応しない」とかなんとか抜かされまして。
いや、そのコントロールを使う要求をしたわけでもないんだし、そりゃないでしょ。
しょうがないので代わりに対策しましたよ。ええ。
MSのバグだって免罪符にはならないのにね。
ツールにバグがあるのはやむを得ないとして、最終製品に対してきちんと責任を持ちましょうという話。