09/03/11 00:43:02
IDisposable継承してるとGC上の世代が繰り上がって
解放が遅れるんじゃなかった？
753:デフォルトの名無しさん
09/03/11 00:44:03
IDisposableはGCと直接は無関係
実装するとGCのタイミングが遅れるのはファイナライザ
754:デフォルトの名無しさん
09/03/11 00:48:58
>>751
初心者スレだからこんなことで熱くなるんだよ。
755:デフォルトの名無しさん
09/03/11 00:51:57
いまどきDisposeでこんな話になるとはね
IDisposableはインターフェースで実装されてるんだから
あれば実行すべきなんだよ
全部自動なんだぜって話ならobjectにdisposeが実装されてる
756:デフォルトの名無しさん
09/03/11 00:52:41
冷蔵庫を開けっ放しにしていても、ママンが気付いて閉めてくれるから、自分で閉める必要はないし、
部屋を散らかしていても、ママンが片付けてくれるから、自分で片付ける必要はない。
ってことだろ？
757:デフォルトの名無しさん
09/03/11 00:53:40
>>753
ありがと
勘違いしてた
必ず一回目のgcで生き残ってしまうため、結果的に世代が上がってしまうって理由もさっき知った
758:デフォルトの名無しさん
09/03/11 00:55:04
>>756
ママンはちらかった部屋をいつ片付けてくれるかわからない
A. だから自分で片付けたほうがすっきりして気持ちがいいんだぜ
B. でもいつかは片付けてくれるんだから放置しとくんだぜ
ってことじゃね？
759:デフォルトの名無しさん
09/03/11 00:56:01
電機式ストーブに喩えるなら、
・Dispose別にいらないよ派
「サーモスタットがついてる器具なら、温度は一定以上にならないから、別にこまめに電源切る必要はないよ」
・Dispose呼んだほうがいいよ派
「サーモスタットついてるかもしれないけど電気代の節約のためにこまめに切ったほうがいいよ。」
・Dispose絶対要るよ派
「ストーブにそんな機能あるかどうか分からないから、とにかく切ったほうがいいよ」
760:デフォルトの名無しさん
09/03/11 00:58:04
>>758
C#の場合は、
ママが片付けてくれるものは放置してママに任せて、そうでないものは仕方が無いから自分でするしかない
だな。
761:デフォルトの名無しさん
09/03/11 00:58:31
>>758
というより
ママンがいつ冷蔵庫を締めてくれるかわからない
Ａ 冷蔵庫にはアイスが入っていて、溶けると嫌だから自分で締めるぜ
Ｂ 冷蔵庫にはアイスが入っていなくてどうでもいいからママンに任せるぜ
ってことかな？
762:デフォルトの名無しさん
09/03/11 01:01:18
何か違う
763:デフォルトの名無しさん
09/03/11 01:03:39
>>761
さっきの奴は、アイスが入っているのにBを選択してしまって、
「溶けてはいるが、溶けてもアイスであることに変わりはない」
って主張していたってことか
納得
764:デフォルトの名無しさん
09/03/11 01:05:00
いや意味不明だろw
765:デフォルトの名無しさん
09/03/11 01:06:15
アイスが入っているかどうかは、MSDNライブラリと常識で判断しろってさｗ
766:デフォルトの名無しさん
09/03/11 01:07:26
「常に呼ぶ」「常に呼ばない」のどちらかに決めようとするからおかしい。
767:デフォルトの名無しさん
09/03/11 01:08:26
MSDNライブラリには、
アイスが入っている場合に冷蔵庫を締めるためにIMamanableを利用します
って書かれているんだが・・・
768:デフォルトの名無しさん
09/03/11 01:08:33
初心者スレにふさわしい流れにほっこり
769:デフォルトの名無しさん
09/03/11 01:10:48
>>766
IMamanableは、アイスが入っているので締めてね？というために実装するインターフェースです
従って常にアイスが入っているので、締めないとアイスが溶けちゃうんです
770:デフォルトの名無しさん
09/03/11 01:11:05
>>767
そうなんだけど、実際にアイスが入ってるかどうかは常識で判断しろ、
って言い張ってる奴がいるのよ。
確かに、レアケースで入っていると見せかけて入ってないことがないわけ
じゃないんだけどさ。
771:デフォルトの名無しさん
09/03/11 01:12:03
そもそもアイスのメタファーが不適切
772:デフォルトの名無しさん
09/03/11 01:13:45
>>771
アイスだけにシンタックスシュガーです
773:デフォルトの名無しさん
09/03/11 01:14:39
早くリソースを解放したいなら呼び出せばいい。
そうでないなら必ずしもこだわる必要はない。それだけのことだな。
774:デフォルトの名無しさん
09/03/11 01:14:50
ようは、「常に」「必ず」「絶対」が、100回中100回なのか、
100回中95回なのか、って話。
前者にこだわる原理主義者と、後者でいいじゃんっていう
一般人の戦い。
775:デフォルトの名無しさん
09/03/11 01:15:12
Dispose呼ばないとおかしくなる可能性がある
どのクラスがどれだけヤバいかは内部実装によるので外部仕様から正確な判定は困難
なら、必ず呼んどけ
というのは別におかしなことじゃない
それを
呼ばなくてもよい場合がある
それは常識で判断できる
だから呼ぶか呼ばないかは常識で判断しろ
なんていうやつがいるから混乱する
776:デフォルトの名無しさん
09/03/11 01:15:50
>>770
それは、アイスが入っていないのに、アイスが入ってるから締めてねって言うようなもんじゃんｗ
アイスが入ってると思って締めざるを得ないｗ
777:デフォルトの名無しさん
09/03/11 01:17:23
>>775
それはクラス設計に問題が…
「Dispose呼んでもバグがある可能性があるから、
呼ばないほうがいい」って言ってるのと、内容は正反対でも同レベルだぞ。
778:デフォルトの名無しさん
09/03/11 01:17:48
>>774
その残りの5回中にFileStreamを開いたり、DBに接続してたりしてたら
問題になるから回数や割合の問題じゃないんだが・・・
779:デフォルトの名無しさん
09/03/11 01:20:42
>>775
だからファイナライザでDispose処理をしておくことが推奨されている
IDisposableを実装するなら、別にファイナライザを定義する必要はないが、
最終的にリソースが解放されるようにしておくのは当然
780:デフォルトの名無しさん
09/03/11 01:21:07
>>777
全然違う
Disposeはインスタンスの寿命が終了することを前提で呼ばれるメソッドで、
設計もそのようになされているから、インスタンスを使わなくなった時に
Disposeを実行して問題が発生するようなら、むしろそのほうがおかしい。
781:デフォルトの名無しさん
09/03/11 01:21:21
>>778
でも、呼んだら問題が発生するから呼ばないでください、って注意書きがあれば
呼ばないでしょ？
ほら！ 100回中100回じゃないじゃないか！ って言ってるのが原理主義者。
782:デフォルトの名無しさん
09/03/11 01:22:45
>>779
リソースの即時解放として実行するのはまったく問題ないじゃん
783:デフォルトの名無しさん
09/03/11 01:23:56
>>780
そういうこと言ってるんじゃなくて、Disposeメソッドそのものに
バグがあるかもしれないでしょってことを言ってるんだが
Dispose呼ばなきゃ不具合が起きるクラスなんてそれと同レベル
784:デフォルトの名無しさん
09/03/11 01:24:29
>>781
それアイスが入ってるけど、冷蔵庫しめないで下さいねって注意するぐらい愚問
785:デフォルトの名無しさん
09/03/11 01:25:51
リソースはアイスではない
786:デフォルトの名無しさん
09/03/11 01:27:46
>>783
終了処理を行わないと問題が起きるAPIなんて糞あるだろ？
その終了処理を行うために実装されるのがIDisposableで、Disposeなんだから、
極端に言えば、Dispose呼ばなきゃいけないと不具合がおきるクラスなんて
腐るほどあるからDisposeしたほうがいいっていってるわけ。
これが、なんで理解できんの？
787:デフォルトの名無しさん
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．アイスがハーゲンダッツなのでちゃんと締める。