アカウント名:
パスワード:
Operaが本質的に安全だからですか? (そんなわけない、シェアが低いからに決まってるだろJK)という反語のつもりだったのですが。
大丈夫。ほとんどの人には通じている。通じている人はコメントを書かないだけ。
#屋上屋を重ねているだけなのでAC。
# じゃあ一体どうしろと
素人考えですが、その「Microsoft 製品のバグだろう」と思っている現象を Microsoft Connect [microsoft.com] で報告して他の人がバグであることを確認してくれれば、技術者相手には自分のせいでないと説得することができると思います。日本語の報告も受け付けていて [microsoft.com]、日本語の報告を Microsoft の担当者が英語に訳す場合もあるようです。 Connect はほとんど使ったことがないので、どのくらい他の人が再現に協力してくれるものかはわかりませんが。
ただし、バグ報告を書くのは手間がかかるかもしれませんし、 Connect では技術者以外には説得材料にならないでしょうね。
ところでそれ、最近の流行でいえばRuby流というか、こういう感じには書けないんでしょうか?HogeForm.ShowDialog do |form| xxxxxend
using( var form = new HogeFrom() ){ form.ShowDialog();}
formのスコープが明確になるし、Dispose()の呼び出しも保証されます。
そう。そしてusingは使っていないがちゃんとDisposeしているのにメモリリークするというのが元に書かれたバグでしょう。CE の環境がないので試せていませんが。
HogeForm.ShowDialog do |form| xxxxxend
これをこんな風に書く必要があるんでしょう。
HogeForm.ShowDialog do |form| xxxxx form = nullend
なんだそれと思ったらその感覚が正しい(笑)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
本当にバグの場合もあるけど (スコア:5, 参考になる)
はまった内容:
悪い例:
Form form = new HogeForm();
form.ShowDialog();
form.Dispose();
良い例:
Form form = new HogeForm();
form.ShowDialog();
form.Dispose();
form = null;
最後にnullを設定しないと、このフォームがガベージコレクトされず、
メモリリークします。なんだそれ。
マイクロソフトのサポートに問い合わせたところ、
マイクロソフト側でも現象を確認したそうで、
回答が「最後でnullを設定してね」でした。
マイクロソフトはバグとは言いませんでしたが、どう見てもバグですね。
メモリリークするよ~、あんたのコードが悪いんでしょ~、
なんとかしてよ~、とつつかれて大変でした。
Re:本当にバグの場合もあるけど (スコア:5, 参考になる)
いまどき Web アプリを作ると Encoding は ふつー utf8 ですよね。
ある日、お客さまから文字サイズがころころ変わるバグがあるからさっさと直せとのご連絡。
そういわれましても、そもそも表示文字サイズを変えるような処理をしていないのです。
お客さまのところへ伺ったところ、IE6 で表示文字サイズを最大にしてご利用でした。
確かに mouse cursor が anchor element の上を通るときに文字サイズが変わる。
勘のいい方はお気づきのように、IE7 だと問題ありません。
結局、IE6 の既知の問題とわかりました。
リンクをクリックすると文字のサイズが中に戻る
http://support.microsoft.com/default.aspx?scid=kb;ja;896315 [microsoft.com]
公式な対策は、リンク元のHTMLの文字コードをShiftJISにてエンコードしてください、とのこと。
すでに obsolette な IE6 だけのために utf8 をやめるわけにもいかず、
かといってお客様は IE6 でないと動かない Web アプリを多用してるらしく、
IE7 に入れ替えるのは無理とのこと。
説明でお客様も一応は納得してくれたのですが、腑に落ちない様子なので、
お客様の選択のひとつとして、IE6 と併用できる Firefox を紹介しておきました。
まあ、そんな事例もあったということで。
Re:本当にバグの場合もあるけど (スコア:4, 参考になる)
IEのバグリスト [infoseek.co.jp]をMozilla [infoseek.co.jp]やSafari [infoseek.co.jp]、Opera [infoseek.co.jp]と比較すると数の違いに驚かされます。しかも、これは独自仕様に基づく動作の違いを含みません。
W3Cの仕様に基づき記述したものが記述通りに動かないのは、原因が何であれ使用者側から見ればバグでしょう。
まあ既知のバグを回避するのも技術者の仕事のうちではありましょうが、こうも多いと完全回避が困難である場合も……
Re:本当にバグの場合もあるけど (スコア:2, すばらしい洞察)
Re: (スコア:0)
Bugzilla@Mozillaでコンポーネントをレイアウトだけに絞って検索しても星の数ほどバグが出てきます。
確認されているセキュリティホールの数はOperaが断然少ないのですが、それは本質的にOperaが安全だからでしょうか?
Re: (スコア:0, 既出)
挙動とかレイアウトにかかわるものはわりに見つかりますが、
セキュリティに関係するものは狙って探さないと見つかりにくいですし。
(通常使用で表に表れない)
Re: (スコア:0)
Re: (スコア:0)
大丈夫。ほとんどの人には通じている。通じている人はコメントを書かないだけ。
#屋上屋を重ねているだけなのでAC。
Re: (スコア:0)
それだけでなく、
たとえばFxのバグは見つかるごとに少しずつつぶされていますが、
IEのバグは大半ホッタラカシなんですよね。メジャーバージョンアップ後ですら…。
Re:本当にバグの場合もあるけど (スコア:4, 興味深い)
お願いだから直してくださいとMSに半年くらい頼み込んで、やっとパッチを出してもらった。これで安心と思ったら、サービスパックで元に戻りやがったー!!
ということが、ごくごく最近にありました。SPへのパッチはいまだに出てません!
Re: (スコア:0)
Windows環境でしか再現しないし、テスト環境にSP全部用意とか厳しいから
ホント勘弁。
# ずいぶん前のことだけどAC
Re: (スコア:0)
MSをもっとプッシュしてください。
ドライバ開発者の皆さんの努力で快適なWindowsが維持されていると
一ユーザーとして思います。
みなさんの努力に感謝。
Re:本当にバグの場合もあるけど (スコア:1)
Re:本当にバグの場合もあるけど (スコア:2, 参考になる)
もちろん、スコープから外れても、ガベージコレクトされずに
フォームオブジェクトが丸ごと残り続けてました。
で、最終的にはOutOfMemoryExceptionになってしまいます。
nullでリセットするようにしただけで解決しましたけどね。
他にも、Windows CEの.NETの怪しい挙動をいくつか見つけており、
(問い合わせてはいませんが)たぶんMSのバグだべ~と思っています。
#↑で、こういう態度をとると
# 「すぐにMSのせいにする技術者」
# ってことになっちゃうんだな。
# じゃあ一体どうしろと
Re:本当にバグの場合もあるけど (スコア:2, 参考になる)
素人考えですが、その「Microsoft 製品のバグだろう」と思っている現象を Microsoft Connect [microsoft.com] で報告して他の人がバグであることを確認してくれれば、技術者相手には自分のせいでないと説得することができると思います。日本語の報告も受け付けていて [microsoft.com]、日本語の報告を Microsoft の担当者が英語に訳す場合もあるようです。 Connect はほとんど使ったことがないので、どのくらい他の人が再現に協力してくれるものかはわかりませんが。
ただし、バグ報告を書くのは手間がかかるかもしれませんし、 Connect では技術者以外には説得材料にならないでしょうね。
Re:本当にバグの場合もあるけど (スコア:1)
Re:本当にバグの場合もあるけど (スコア:1, すばらしい洞察)
「おそらく .NET Compact Framework の garbage collection のバグです」とかいえば
「MSのバグ」ほど馬鹿っぽく聞こえなくなりますよ?
# 問題は何も解決しませんけど
Re: (スコア:0)
Re:本当にバグの場合もあるけど (スコア:1)
まだDOSが当たり前だったころ、当然16ビット用のアプリなんですが、
スタック領域を8000hバイトと指定してMASMでアセンブルしたら、
なぜか符号拡張されてFFFF8000hバイトの確保に走り、メモリ不足のアセンブルエラーとなりました。
しょうがないので7C00hぐらいに減らして回避しましたが。
その2
VB 4.0のthreed.ocxは普通に使うだけでメモリリークする困ったやつなわけですが、
これを使ったアプリが長時間連続動作で落ちるという状態になりまして。まぁ当然なんですが。
開発元に連絡したところ、「それはMSのバグなんでうちは対応しない」とかなんとか抜かされまして。
いや、そのコントロールを使う要求をしたわけでもないんだし、そりゃないでしょ。
しょうがないので代わりに対策しましたよ。ええ。
MSのバグだって免罪符にはならないのにね。
ツールにバグがあるのはやむを得ないとして、最終製品に対してきちんと責任を持ちましょうという話。
Re:本当にバグの場合もあるけど (スコア:1)
ポインタ変数にNULL入れるとそのときも解決しましたが・・・
Re: (スコア:0)
Re: (スコア:0)
あれはGCでなくリファレンスカウンタでしかなく、NothingをSetする必要がある。
しかしC#/VB.NETはGC。
.NET Compact Frameworkはその手の不備ありまくりなので、null/Disposeは明示的にするのが吉。
Re:本当にバグの場合もあるけど (スコア:2)
だから、 Dispose() を明示的にコールしているのに、リソースが解放されないよ、変な実装だね。って話でしょう。
Re: (スコア:0)
変数にnullを設定して参照をなくさないとGCが働かないのが不具合というのが元コメント。
本来はスコープを抜けたら参照が破棄されるので一々nullを設定する必要はない。
Dispose()で解放するリソースは、この場合はformの中。
form自体は参照が残っているのでまだGCの対象外。
Dispose()呼ぶだけじゃ駄目という悲しい現実。
「「書かせること」が変わってない」は確かに同意。
むしろ例外がある分余計辛いかも。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
ところでそれ、最近の流行でいえばRuby流というか、こういう感じには書けないんでしょうか?
HogeForm.ShowDialog do |form|
xxxxx
end
Rubyのブロックの使い方の1つとして、
それこそ今回のよう(?)な、リソース開放の手順を隠蔽する道具として使う、というのが有るもので。
open(filename) do |f|
f.xxxx
end
などと書くと「ファイルを開いてブロック内でxxxxさせて、それが終わるとファイルを閉じる」ってのをやってくれる。
こういう書き方が出来るならば、Disposeだろうが=nullだろうが何が来ようが怖くない。みんな隠蔽できるのだから。
この
Re:本当にバグの場合もあるけど (スコア:2, 参考になる)
Re:本当にバグの場合もあるけど (スコア:1)
そう。そしてusingは使っていないがちゃんとDisposeしているのにメモリリークするというのが元に書かれたバグでしょう。CE の環境がないので試せていませんが。
これをこんな風に書く必要があるんでしょう。
なんだそれと思ったらその感覚が正しい(笑)
LIVE-GON(リベゴン)
Re:本当にバグの場合もあるけど (スコア:1)
問題は、.NET Frameworkという腐ったライブラリ。
個人的には、Microsoftの製品は、上のレイヤーにいくほどダメな仕様になることが多いと思う。
カーネルとか、.NET CLRとか、C#とか、すごく良くできていると思うんですけどねぇ。
Re: (スコア:0)