09/03/10 23:45:09
>>692
>別におかしくはないよ。でもそれはIDisposableの「最低限度の実装」をしたクラスについてだよね。
>でも実際にIDisposableを実装したクラスは、それ以上の実装をしているのが普通なわけ。
最低限がアンマネージリソースの解放で、それ以上の実装をしているなら、もっと実行しないと駄目だろ。
695:デフォルトの名無しさん
09/03/10 23:45:45
>>690
それは完全に別問題では？
Flushの動作はIDisposableの実装で求められている動作とは関係ないし。
内容がロストすることが常に不具合とも言い切れないし。
例えばユーザが明示的に「保存」を選択するまで保留するという手もある。
696:デフォルトの名無しさん
09/03/10 23:46:43
>>692
>実際にIDisposableを実装したクラスは、それ以上の実装をしているのが普通
どんなすごい実装をしているかどうかなんてわからんだろ
だからDisposeしろって話になってるのがわからんのか？
697:デフォルトの名無しさん
09/03/10 23:47:06
>>694
それ以上の実装をしていれば、「アンマネージリソースの解放」は
明示的にDispose()を呼ばずともサポートされる。
もちろん明示的に呼び出すこともできる。
698:デフォルトの名無しさん
09/03/10 23:47:46
>>695
お前が荒らしレベルで、プログラマとして最底辺だということがわかったよ
699:デフォルトの名無しさん
09/03/10 23:49:30
>>696
FCLのクラスについては実質保証されてるでしょ。
心配ならDispose(bool disposing)などが実装されているかMSDNで調べればいい。
原則としてDispose()を呼ぶという態度はいいとしても、
FCLのクラスに対して特別扱いするのは別に不自然じゃないと思うぞ。
基本はGCに任せるほうが必要or不必要の判断に関しては確実だしな。
700:デフォルトの名無しさん
09/03/10 23:50:34
>>697
へーGCによってDispose()が実行されなくとも、プログラマが明示的にDisposeを呼ばずとも
自動的に解放してくれるわけね
すごいね
701:デフォルトの名無しさん
09/03/10 23:50:58
>>695
それだと保存が押されたらDisposeすると言っているように感じるが、
その意図でレスしたの？
702:デフォルトの名無しさん
09/03/10 23:51:29
>>698
もしFlush()が確実に必要な処理なら、MicrosoftはファイナライザやDisposeでFlush()されるように実装している。
そうなってないってことは、Flush()は必ずしも必要とされていないということだよ。君こそ大丈夫か？
703:デフォルトの名無しさん
09/03/10 23:52:03
>>699
>FCLのクラスについては実質保証されてるでしょ。
なんでいきなり条件を付けた論議なの？
704:デフォルトの名無しさん
09/03/10 23:53:23
と言うかさ、精神衛生上Disposeしないと気持ち悪くない？
usingで囲むべきだと思うがね
705:デフォルトの名無しさん
09/03/10 23:53:24
MS のやることは正しい、MS の開発者の意見は正しい、
って盲目的だなぁ。
Dispose() を呼ぶことで安全が買えるなら、よっぽど
その方が楽でしょ。
706:デフォルトの名無しさん
09/03/10 23:53:36
>>697
どうやって明示的にDispose（closeその他も）しなくて、
アンマネージリソースが会話されるの？
707:デフォルトの名無しさん
09/03/10 23:54:00
>>701
違う。保存が押されてから、Flush()なりClose()なりを呼べということだ。
もちろんソフトによりけりなので、すぐにFlush()やClose()を呼んだほうがいいこともある。
しかし保存が押されてからストリームに反映させたい仕様だと、すぐにFlush()するのは良くないだろう。
708:デフォルトの名無しさん
09/03/10 23:54:25
>>704
using なしでも、スコープ抜けたら自動的に Dispose() が呼び出されるくらいでいいと思う。
何かしらの理由で呼ばれたくないときだけ、何かのメソッドを呼び出してマークするとか。
709:デフォルトの名無しさん
09/03/10 23:54:40
>>702
そのために必要なのが、Disposeでしょ？
IDisposableが、なんでインターフェースとして存在しているか理解してる？
710:デフォルトの名無しさん
09/03/10 23:55:23
>>708
c++/CLRはスコープ抜けるとDisposeが実行されるね
711:デフォルトの名無しさん
09/03/10 23:56:56
>>704
どうしてアンマネージリソースにだけそう思うのか不思議。
>>705
Dispose()を呼び出すことによるその後のトラブルもありうるわけで。
>>706
まともなクラスなら、Finalize()経由でリソースは解放される。
マトモじゃないクラスなら、そんな仕様はないので、
自ら確実にdispose()を呼び出す必要がある。でもそれを忘れると、
メモリリークなどの危険性があるので、そんなクラスの使用はおすすめできない。
712:デフォルトの名無しさん
09/03/10 23:56:59
>>710
訂正
C++/cli
713:デフォルトの名無しさん
09/03/10 23:57:55
Disposeを呼ばないとマネージリソースの不足によって致命的な不具合が
発生する可能性があるけどDisposeを呼ぶことで問題になる可能性はない
だから呼ぶべき
.NETのGCはマネージリソースを適切に管理するためのもので、
アンマネージリソースに関してはほとんどのクラスで解放までの
サポートはあってもそのタイミングに関しては関知しない
よってタイミングをGCにまかせるという選択肢はない
714:デフォルトの名無しさん
09/03/10 23:58:12
>>711
Dispose() を呼び出したことによるトラブル、って今のところ出会ったことがない。
どんなトラブルがあんの？
715:デフォルトの名無しさん
09/03/10 23:58:18
>>702
>もしFlush()が確実に必要な処理なら、MicrosoftはファイナライザやDisposeでFlush()されるように実装している。
>そうなってないってことは、Flush()は必ずしも必要とされていないということだよ。君こそ大丈夫か？
残念ながらMSの公式見解は違う。
あんまり推測で適当なこと言わない方が良いよ。
URLﾘﾝｸ(blogs.msdn.com)
>The reason is that (normal) finalizers aren't ordered -
>any two objects may be finalized in any order,
>or at the same time if we add multiple finalizer threads in a future version.
というわけで解放順の問題。
716:デフォルトの名無しさん
09/03/10 23:59:14
>>711
なるほど、FileをOpenするクラスや、データベースへの接続はするべきじゃないということですね。
あんたが普通に開発したこともないプログラマだということがよくわかったよｗｗｗ
結局>>678が真理だったな
「アンマネージドリソース=メモリの消費」
だと思っていたサンデープログラマか。
死んでいいよ。
717:デフォルトの名無しさん
09/03/11 00:01:46
メモリの消費に関してもDisposeは必要
アンマネージメモリは完全にGCの管理外だから
マネージメモリみたいにメモリ使用量と照らし合わせてGCが適切に管理してくれたりしない
718:デフォルトの名無しさん
09/03/11 00:02:51
>>702
それは違うと思う。
ファイナライザの段階では先に中のStreamが無くなっている可能性があるため、
StreamReaderとWriterはFlushを呼びたくても呼べない。
一般にファイナライザでメンバがまだ残っている保証はないとMSDNにも書いてあるはず。
719:デフォルトの名無しさん
09/03/11 00:03:13
>>715
そこにnormalって書いてあるとおり、それは普通の方法ではの話だろう。
そりゃ普通のFinalizeじゃ他のマネージオブジェクトにアクセスすべきではない。
しかし、もし確実にFlush()される必要があるなら、Attributeなどを使ってでも確実に実行されるようにするよ。
結局しないのは技術的問題というより、そうしないのが自然だからだよね。
>>716
ファイルにしろデータベースにしろ、普通は明示的にDispose()を呼ばなくても、
リソースは解放される。
720:デフォルトの名無しさん
09/03/11 00:07:03
たかがDisposeごときでこんなに熱くなれるとは
721:デフォルトの名無しさん
09/03/11 00:07:26
>>717
誰もそこは否定していないのでは？
ただ、アンマネージリソースを有するマネージオブジェクトの
寿命自体はGCで判断できるから、GCがそのFinalizeを呼び出してから、
アンマネージリソースを解放するというのでも通常遅くは無い。
それだけの話だと思うが。
722:デフォルトの名無しさん
09/03/11 00:08:52
>>719
>ファイルにしろデータベースにしろ、普通は明示的にDispose()を呼ばなくても、リソースは解放される。
>ファイルにしろデータベースにしろ、普通は明示的にDispose()を呼ばなくても、リソースは解放される。
>ファイルにしろデータベースにしろ、普通は明示的にDispose()を呼ばなくても、リソースは解放される。
言ってる事理解してる？
723:デフォルトの名無しさん
09/03/11 00:09:10
＞通常遅くは無い。
これが間違い
724:デフォルトの名無しさん
09/03/11 00:10:09
関係ないけど解放処理が必ず実行されることを保障するには普通のファイナライザでは不十分
CriticalFinalizerObjectを使うことになる
725:デフォルトの名無しさん
09/03/11 00:11:59
>>723
遅くはないな。それが間違いというなら、C#のGC自体を否定しなきゃいけないかも。
GCが参照されていないインスタンスを破棄するタイミングが制御できないといっても、
通常そこまで時間はかからない。必要がなくなりゃどのみち勝手にリソースは解放される。
そのタイムラグが気になる状況なら明示的にDispose()を呼び出せ、としか言いようが無い。
726:デフォルトの名無しさん
09/03/11 00:12:43
ところで.NET Frameworkってプロセス終了時にすべてのオブジェクトの
ファイナライザが呼ばれることが保証されてる?
727:デフォルトの名無しさん
09/03/11 00:13:13
>>725
>そのタイムラグが気になる状況なら明示的にDispose()を呼び出せ、としか言いようが無い。
この後の及んで着地点かｗ
728:デフォルトの名無しさん
09/03/11 00:13:27
保証されてません
usingやfinallyも同様です
>>724のようにCriticalFinalizerObjectを使う必要があります
729:デフォルトの名無しさん
09/03/11 00:14:29
>>725
C#のGCはマネージリソースを管理するためのもの
話をまぜるな
＞通常そこまで時間はかからない
だから通常とか普通とか適当なこというなって
730:デフォルトの名無しさん
09/03/11 00:15:07
>>727
最初からそういう話だと思うが。
誰もDispose()を呼び出すななんて言ってない。
「絶対呼び出せ」とか言ってる人がいるから叩かれるだけで。
少なくともFCLの多くのクラスでは、絶対に呼び出す必要まではない。
731:デフォルトの名無しさん
09/03/11 00:17:26
所詮おまえらなんか糞プログラマなんだよ
>C#は生産性高い。
>オブジェクト指向と関数型と手続き型が交じり合って溶け出すような見事なソースコードが作れる。
>しかし2chとか見ててもついてけてる奴はあまりいないみたいだな。
>ちょっと前に2chで関数型ユーザーを叩いてみた
URLﾘﾝｸ(d.hatena.ne.jp)
「しかし2chとか見ててもついてけてる奴はあまりいないみたいだな。」
これが真実
732:デフォルトの名無しさん
09/03/11 00:17:54
>>729
アンマネージリソースをC#のクラスにラップして利用してるんだから、
マネージリソースやGCは無関係ではないよ。
アンマネージリソースを解放すべきときは、
それをラップしたマネージリソースが不要になるときでもあるからね。
そのクラスのインスタンスが不要かどうかの判断は、
GCが一番良く知っている。GCに頼れば、他から参照が残っていたり、
解放したあとにそのインスタンスを利用することもないだろう。
733:デフォルトの名無しさん
09/03/11 00:18:52
>>732
もう言ってる事が支離滅裂だな
734:デフォルトの名無しさん
09/03/11 00:19:27
分からないので教えてください。
カスタムコントロールのリストをもたせたクラス用のCollectionEditorを作っています。
リストはカスタムコントロールの基底クラス(abstract)の集まりなので、
[Attribute]を使って登録する派生クラスのTypeを登録しようかと思ってます。
今、派生クラスの定義のところに
[Attribute名(typeof(派生クラス名))]
としているのですが、typeof～の部分なしで同じようなことをする方法はありませんでしょうか？
ToolStripとかを見ていると上手くやっているように見えるのですが…
735:デフォルトの名無しさん
09/03/11 00:20:01
>>730
少なくともお前の作ったソフトだけは使いたくない
これはここにいるすべての人が一致するところ
736:デフォルトの名無しさん
09/03/11 00:20:29
で、Dispose() を呼び出したことによるトラブルの実例はまだ？
737:デフォルトの名無しさん
09/03/11 00:21:34
>>733
ごく当たり前のことを言ってるに過ぎない。
そもそも、そこまでリソースのマネジメントに敏感にならざるを得ない状況なら、
C/C++などを使うべきだと思うよ。
もちろん、じゃあどんな場合もDisposeするなとも言ってないのであしからず。
738:デフォルトの名無しさん
09/03/11 00:22:14
>>737
>もちろん、じゃあどんな場合もDisposeするなとも言ってないのであしからず。
どんどん変わってきてるじゃん 主張が
739:デフォルトの名無しさん
09/03/11 00:23:21
>>737
じゃ、アンマネージドリソースを解放する場合などには、
Disposeする必要があるということは理解したということだな？
740:デフォルトの名無しさん
09/03/11 00:24:13
>>736
上で紹介されてるじゃん。
あるオブジェクトが、他のクラスのメンバから参照されているときに、
そうと知らずにDisposeしてしまうケースとかね。
>>738
最初から同じ主張ですが。
741:デフォルトの名無しさん
09/03/11 00:25:23
>>739
Dispose()じゃなくてDisposeなら、そう。
てか何度も言ってることだが。
742:デフォルトの名無しさん
09/03/11 00:26:34
Javaでメソッドの終わりに必ずnullを代入しろとかいう(基地外みたいな)話の延長みたいだな
743:デフォルトの名無しさん
09/03/11 00:26:50
>>731
ソースコードによる自動シリアライズ に噴いたｗｗこの発想はなかったｗｗｗ
744:デフォルトの名無しさん
09/03/11 00:30:41
>>741
じゃ、互いの主張は一致したな。
アンマネージドリソースを使用している可能性があり、
もうこれ以上必要がなくなったらDisposeする
これでいいな？
745:デフォルトの名無しさん
09/03/11 00:32:13
>>734
言ってることがよくわからない
その属性をどうやって処理するつもり?
746:デフォルトの名無しさん
09/03/11 00:32:58
というか、必要条件と十分条件の区別程度の知恵もない人間が
プログラマやっちゃダメだと思うんだが、このスレ見ると日本のプログラマって
本当底辺の職業なんだなという思いを深くするな。
だから、可及的速やかに開放すべき共有資源を抱えているクラスは必ずDisposeを
実装しているが、逆は真ならず、それだけの話なんだが。。
747:デフォルトの名無しさん
09/03/11 00:37:32
>>746
「必ず」とは限らない。バグのあるクラスもあるからね。
お前さんの言ってるのは↑こんなレベルなんだが。
748:デフォルトの名無しさん
09/03/11 00:38:01
>>746
というか、文意や話の流れ程度を読む知恵もない人間が
プログラマやっちゃダメだと思うんだが、このスレ見ると日本のプログラマって
本当底辺の職業なんだなという思いを深くするな。
だから、可及的速やかに開放すべき共有資源を抱えているクラスばかりが必ずDisposeを
実装しているわけじゃないってところをぐだくだ言ってるやつがいるという話なんだが。。
749:デフォルトの名無しさん
09/03/11 00:38:05
>>731
>>743
なんという発想w
どうせならCodeDOMじゃなくてLCG使おうぜ
750:デフォルトの名無しさん
09/03/11 00:38:55
いやソースコードに意味があるのか
751:デフォルトの名無しさん
09/03/11 00:40:39
ここって一応初心者スレなんだよな・・・
なんか自信なくなってきた 皆凄すぎ
やっぱ参考書3,4冊じゃまだ追いつけない
752:デフォルトの名無しさん
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．アイスがハーゲンダッツなのでちゃんと締める。