09/03/11 01:30:39
>>786
C使って生API叩いてるなら至極正論だが、
.NETの世界でC#使っているなら、そうじゃいけないだろ。
結局、「メモリを確保したら必ず忘れずに解放しましょう」
っていう単純なルールを守るのが一番難しいし、ガベージコレクタの
無いCのような言語では最もエラーの温床となりやすい。
そのエラーを極力無くしましょうってのがC#なんだから、
終了処理を必須とするクラスの設計は避けたほうがいい。
788:デフォルトの名無しさん
09/03/11 01:31:39
>>787
>終了処理を必須とするクラスの設計は避けたほうがいい。
だから、終了処理が必須だからDisposeがあるといってるんですｗ
789:デフォルトの名無しさん
09/03/11 01:32:30
＞極端に言えば、Dispose呼ばなきゃいけないと不具合がおきるクラスなんて
まずこの具体例を挙げて。どういう状況かもコードつきで詳しく。
790:デフォルトの名無しさん
09/03/11 01:33:52
>>788
終了処理の明示的な呼び出しを忘れてもカバーできるように
設計することが推奨されているし、そうするのが当然。
791:デフォルトの名無しさん
09/03/11 01:36:36
>終了処理が必須だからDisposeがある
またデマカセが始まったw
792:デフォルトの名無しさん
09/03/11 01:37:08
無限ループって怖くね？
793:デフォルトの名無しさん
09/03/11 01:39:24
>>790
すぐに解放しないと問題がある場合があるから、
すぐにした方がいいっていってるんじゃんかよ
794:デフォルトの名無しさん
09/03/11 01:40:04
break
795:デフォルトの名無しさん
09/03/11 01:40:33
>>791
いやMSDN読めば？
そういう目的のために存在するんだから、必須だからDisposeがあると考えるのが必然
796:デフォルトの名無しさん
09/03/11 01:41:08
>>793
すぐに解放しないと問題が起きるならすぐにすべきに決まってるだろ。アホか？
797:デフォルトの名無しさん
09/03/11 01:42:16
>>796
>終了処理を必須とするクラスの設計は避けたほうがいい。
って言う奴がいるから、わざわざ指摘してるんでしょうがｗ
798:デフォルトの名無しさん
09/03/11 01:43:24
>>795
どこにそういうことが書いてあるの？きちんと引用して示してね。
799:デフォルトの名無しさん
09/03/11 01:44:10
>>798
リファレンス引く事も出来ないバカ
800:デフォルトの名無しさん
09/03/11 01:45:42
>>799
ごまかさないで示せよ
「終了処理が必須だからDisposableがある」なんてどこに載ってるの？
801:デフォルトの名無しさん
09/03/11 01:46:05
>>798
なんども出てるけど、はいどうぞ
>このインターフェイスは主に、アンマネージ リソースを解放するために使用します。
URLﾘﾝｸ(msdn.microsoft.com)
802:デフォルトの名無しさん
09/03/11 01:48:21
>>801
「終了処理」なんて言葉は書かれていないよね。
ごまかさないようにね。
アンマネージリソースの解放 → 終了処理 かもしれないけど、
終了処理 → アンマネージリソースの解放 は成り立たないからね。
十分条件・必要条件も分からないバカが書き込みしてるのかな？
言葉はきちんと使おうね。まあ揚げ足取りだと吠えるしかできないんだろうけどw
803:デフォルトの名無しさん
09/03/11 01:49:05
>>802
はいどうぞ
>このインターフェイスは、Disposeメソッドだけを定義している。
>使い終わったら確実に資源を解放する処理が必要なクラスは、
>このインターフェイスを実装して、解放処理を記述するのが.NET Frameworkでのお約束である。
804:デフォルトの名無しさん
09/03/11 01:50:33
>>803
あのー頭悪いんですか～？
「終了処理」という言葉を聞いてるんだから、
せめてその言葉が出てくるところを引用しようね。
805:デフォルトの名無しさん
09/03/11 01:51:57
屁理屈の応酬だあ
806:デフォルトの名無しさん
09/03/11 01:52:44
>>804
いやいや、明示的なオブジェクトを破棄するためにDisposeを実装するんだから、間違いじゃないだろ？
何いってんだ？ｗｗ
807:デフォルトの名無しさん
09/03/11 01:53:59
>>804
>「終了処理」という言葉を聞いてるんだから、 せめてその言葉が出てくるところを引用しようね。
必要条件とか言ってるんだから、意味を汲む能力ぐらいあんだろ？
808:デフォルトの名無しさん
09/03/11 01:54:33
>>806
横槍だが、どんどん無知が露呈してるぞ
明示的なオブジェクトの破棄ではなく、明示的なアンマネージリソースの破棄な
オブジェクトというとマネージオブジェクトも含むように聞こえる
809:デフォルトの名無しさん
09/03/11 01:55:55
>>807
なんだ、結局「終了処理」ってのは示せないままか。
とんだヘタレだなwww
810:デフォルトの名無しさん
09/03/11 01:56:53
で、この無意味な言い争いで誰が特をするのか
811:デフォルトの名無しさん
09/03/11 01:56:53
>>808
暗黙的なガベージコレクタでの破棄はFinalize
明示的なオブジェクトの破棄はDisposeだっていってんだろ？
必要条件とかを覚える知識だけあって、文意を汲み取る能力はゼロかよ。
812:デフォルトの名無しさん
09/03/11 01:57:13
さっきから>>788=>>806=>>807が1人で荒らしているような気がしてきた
813:デフォルトの名無しさん
09/03/11 01:57:44
何を今更
814:デフォルトの名無しさん
09/03/11 01:58:38
>>809
オブジェクトを解放する処理＝終了処理と換言しただけでしょうが。
その言葉を使用した文献が見あたらないと負けなの？ｗ
そういう意味の文献があればいいんでないの？ｗ
しぬの？ｗ
815:デフォルトの名無しさん
09/03/11 01:58:38
ここまで自演でした。
816:デフォルトの名無しさん
09/03/11 01:59:51
>>811
完全に間違い。
Disposeはマネージオブジェクトを破棄するところではないし、
破棄できるものでもない。オブジェクト≠アンマネージリソースだよ。
カーネルオブジェクトとかだけをさす言葉じゃないから。
聞いてると用語の使い方が甘い印象を受ける。素人さんかな？
817:デフォルトの名無しさん
09/03/11 02:01:14
>>814
だからオブジェクトじゃないと何度言ったら…。
あ、そっか。荒らしだったのか。相手にするだけ無駄だな…。
818:デフォルトの名無しさん
09/03/11 02:02:23
ここまですべて女子高生の書き込み
819:デフォルトの名無しさん
09/03/11 02:04:09
>>816
>>817
だから、.netで管理できないリソースを明示的に解放するためにDisposeがあるっていってんの
820:デフォルトの名無しさん
09/03/11 02:06:25
>>817
>このインターフェイスは、Disposeメソッドだけを定義している。
>使い終わったら確実に資源を解放する処理が必要なクラスは、
>このインターフェイスを実装して、解放処理を記述するのが.NET Frameworkでのお約束である。
んで、これに対する返事もらってないんだけど？
821:デフォルトの名無しさん
09/03/11 02:09:57
ROMってたけど俺みたいな初心者が見てると気持ち悪くなるわ
何が正しいのやら…
口論終わったらまとめてくれるとありがたい
じゃ、おやすみﾉｼ
822:デフォルトの名無しさん
09/03/11 02:11:35
>>821
Disposeがあればしておけば間違いない
たったこんだけ
823:デフォルトの名無しさん
09/03/11 02:14:06
顔真っ赤にして書き込みすぎちゃってレスできなくなっちゃったんだろうなぁ
ママンはいつまでも面倒みてくれないぞｗ
824:デフォルトの名無しさん
09/03/11 02:15:59
>>823
今頃>>788は顔真っ赤だろうなw
825:デフォルトの名無しさん
09/03/11 02:18:10
>>824
逆だろ>>787が顔真っ赤だろ
826:デフォルトの名無しさん
09/03/11 02:21:29
むしろ今まで書き込んでる奴全員顔真っ赤に見える
827:デフォルトの名無しさん
09/03/11 02:21:56
>>824
アンマネージドリソースを解放する目的で存在するのなら、
disposeを実行するのは絶対に必須だと思うぞ？
828:デフォルトの名無しさん
09/03/11 02:23:12
絶対に必須ってなんだよ。日本語勉強してこい。
829:デフォルトの名無しさん
09/03/11 02:26:13
あーあ反論できなくなっちゃって関係ないこと罵倒し始めたよコイツ
830:デフォルトの名無しさん
09/03/11 02:28:36
宇宙の真理的な絶対に必須とか俺的に絶対必須とか誰も必要としない必須とかいろいろある
831:デフォルトの名無しさん
09/03/11 02:30:31
一般論として、筆者はDisposeメソッドやCloseメソッドの呼び出しを強制するのはあまり
推奨しません。CLRのガベージコレクタはとてもよくできているので、それに任せたほうが
いいからです。ガベージコレクタには、アプリケーションコードがオブジェクトにアクセスし
なくなるタイミングが分かっています。そしてそのタイミングが過ぎたときにだけ、オブジェクト
を回収します。アプリケーションコードでDisposeメソッドやCloseメソッドを呼び出すということは、
アプリケーションは自分がオブジェクトにアクセスする必要がなくなるタイミングが分かっている
と宣言をしていることになります。たいていのアプリケーションでは、オブジェクトが間違いなく
不要になったことがわかることはありません。
例えば、新しいオブジェクトを作成して、その参照を他のメソッドの引数に渡した場合、
そのメソッドが渡された参照を自分のオブジェクトの内部フィールド（これはルートになります）
に格納するかもしれません。メソッドを呼び出した側では、このような動作をしているかどうかは
分かりません。この場合、呼び出し側がDisposeやCloseを呼び出してしまって、その後で
他のコードがそのオブジェクトを利用しようとすると、ObjectDisposedExceptionがスローされる
ことになります。
筆者は、DisposeやCloseを自分のコードで呼び出すのは、次の2つの場合に限ることを
推奨します。１つは、リソースを解放しなければならないことが分かっている時（開いている
ファイルを削除しようとするときなど）です。もう１つは、DisposeまたはCloseを呼び出すことが
間違いなく安全で、しかもオブジェクトをファイナライゼーションリストから削除して、
オブジェクトが昇格するのを防ぐことで、パフォーマンスを向上させたい場合です。
これ以上に説得力のある意見言えるやつ、このスレにはいないわな
有名なAdvanced Windowsとか、これまで何冊も出してる重鎮だろ
書籍でFramework Class LibararyやCLRの実装のミスとかも指摘してるぐらいだからなw
832:デフォルトの名無しさん
09/03/11 02:30:52
どんなに日本語がおかしかろうが、リソース解放にDisposeの実行が明示的に必要なのは変わりない罠
833:デフォルトの名無しさん
09/03/11 02:33:49
>>831
>リソースを解放しなければならないことが分かっている時
まさに今述べてることじゃん
解放しなければ
834:デフォルトの名無しさん
09/03/11 02:35:44
>>833は「次の２つの場合に限る」というのを、どうしても「全ての場合」に摩り替えたい低脳
835:デフォルトの名無しさん
09/03/11 02:42:30
>>834はオブジェクトの生存期間を自分で管理できない最底辺プログラマ
836:デフォルトの名無しさん
09/03/11 02:43:49
今来た初心者の素朴な疑問なんですが、（マジで）
たとえばDBやhttpなどの接続プールを管理しているファクトリからストリームを貰ったときに
自分が使い終わったからといって、勝手に閉じるとママに怒られると思うんですが
そういうケースはどう扱うのが正当ですか？
837:デフォルトの名無しさん
09/03/11 02:49:42
>>836
そのままほっとけばGCが回収してくれると主張する人がいる
838:デフォルトの名無しさん
09/03/11 02:52:08
>>834
だ・か・ら
>アプリケーションコードでDisposeメソッドやCloseメソッドを呼び出すということは、
>アプリケーションは自分がオブジェクトにアクセスする必要がなくなるタイミングが分かっていると宣言をしていることになります。
って書いてあるだろ。つまりオブジェクトが必要無くなったときにdisposeするかどうかを論じてるんだから、
最後の2つの場合について論じているわけよ
839:660
09/03/11 02:57:04
お前らまだ続けてたのか
840:デフォルトの名無しさん
09/03/11 02:59:52
Disposeしていいと思うのならしとけ
していいかわからなかったらするな
これでいいよ
841:デフォルトの名無しさん
09/03/11 03:07:10
しなかったら、ずっとデータベースに接続され続けるんじゃないのか？
していいかわからなかったらしておいたほうがいいだろ
842:デフォルトの名無しさん
09/03/11 04:32:20
A．アイスがチュッチュなら溶けても構わないので、そのまま開けっ放し。
B．アイスがハーゲンダッツなのでちゃんと締める。