ふらっとC#,C♯,C＃（ ..
577:デフォルトの名無しさん
09/03/10 10:55:37
>>574
移動したらビルドじゃ駄目だよ。
念のためクリーンしてからリビルドしてみ
578:デフォルトの名無しさん
09/03/10 10:56:37
.cs,.sln,.csproj以外のファイル全部消してリビルドしてみて
579:567
09/03/10 11:05:41
多数の返答ありがとうございます。
>>576
あー
ビルド→構成マネージャ の表示がそもそもないですね。
でもこの機能2003pro使ってた時に使ってたんで、おっしゃりたい事はわかりました。
デバッグの際にReleaseかDebugか選ぶ項目ですよね。
Expressにはないみたいですね〜。
>>577
クリーンという作業は>>578さんが言っているような事でしょうか・・・
すみません汗
>>578
formのresxっていうのも消したらデバッグエラーが起こるようになってしまい
プログラムが起動しなくなりました。
これも消してよかったんでしょうか。
580:デフォルトの名無しさん
09/03/10 11:20:52
resxも消しちゃダメ
objフォルダとbinフォルダを丸ごと消すだけでいい
Expressにもビルド構成はあるけど既定では表示されてないだけ
ツールーオプションーすべての設定を表示
プロジェクトおよびソリューションービルド構成の詳細を表示，常にソリューションを表示 にチェック
テンプレに入れるべき
581:567
09/03/10 11:26:12
うは！
繋がりました！
とりあえず、obj bin releaseフォルダを全削除してリビルドを行いました。
それでも接続のセッションが上手く行かなかったんですが
imap から pop にサーバーを変更したら繋がるようになりました＾＾；
自宅のＰＣからはimap.google.comに繋がるんですけどね・・・。
不思議な事だ。
みなさんお手間かけさせてすみませんでした
今回の問題の解決にあたり、皆さんの助言のおかげで
副産物がたくさん手に入りました。
とりあえず >>580さんのすべての設定を表示はかましときます！
ありがとうございました〜♪
582:デフォルトの名無しさん
09/03/10 13:51:35
.NET のライブラリのソースコードを、
MSが公開する前から公開してたサイトがあったんだけど、どこだかわかる人います？
以前はググればでてきたんだが、今は「マイクロソフトが公開！」的なブログサイトばかりで見失ったorz
583:デフォルトの名無しさん
09/03/10 14:13:08
自作コンポーネントを作ってGUI上でコンポーネントを
ダブルクリックしたらイベントが自動的に登録されるようなのを
書きたいんですが、分かり易いサンプルないでしょうか。
584:デフォルトの名無しさん
09/03/10 14:19:44
>>582
SSCLIでググればそれっぽいのが出てくるけど
実際の.NETのソースコードと同じである保証はないし公開範囲も狭いよ
やっぱりデバッグ用に公開されてるのを見る方がいい
NetMassDownloader使えばローカルに一括保存できる
>>583
[System.ComponentModel.DefaultEvent("対象のイベント名")]
class MyControl : Control {
585:デフォルトの名無しさん
09/03/10 14:44:43
>>584
よーしダウンロードしてみるぜ！
586:デフォルトの名無しさん
09/03/10 15:12:15
ダウンロードながいな しかもx64もあるからさらに倍か・・
587:デフォルトの名無しさん
09/03/10 15:52:30
ちんこ大きいからサンプルも置いといてやろう
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx
588:デフォルトの名無しさん
09/03/10 16:09:28
太っ腹ですねデブ
589:585
09/03/10 19:04:01
早速、ダウンロードしてみたんだけど、.net2.0でSystem.Webが取得できないみたいなんだけど、
他の人もそうかな？.net3.5なら取得できるんかな。
ダウンロードできないので激しくショックだぜ
590:デフォルトの名無しさん
09/03/10 19:09:18
クラスの破棄について質問なのですが、
~Class()
{}
空のデストラクタを指定するだけでメモリを解放してくれるのでしょうか。
というより、必要がないのですか。
591:デフォルトの名無しさん
09/03/10 19:13:31
IDisposeのあるものは、Disposeをしたほうがいい。
というより、インスタンス生成時にusing句を使ったほうがいい。
IDisposeのないものは、ガベージコレクタが回収してくれるから、そのままでいい。
592:デフォルトの名無しさん
09/03/10 19:19:28
デストラクタでDisposeするのは絶対やってはいけないこと
そもそもPInvokeでアンマネージリソース抱えてたりしない限りはデストラクタは不要
というかパフォーマンスが落ちるので不要なデストラクタは書いてはいけない
593:デフォルトの名無しさん
09/03/10 19:34:18
>>591-592
ありがとうございます。
必要ないわけですか。ということは、
C++でやってた後始末みたいな事がまるで不要という事ですね。
594:デフォルトの名無しさん
09/03/10 19:35:29
IDisposableを実装してようがしてなかろうがGCには回収される
Disposeし忘れてもファイナライザで解放処理が呼ばれるように実装するのが普通だからたいがい大丈夫
ファイナライザが呼び出されてるということは今GCが走ってるわけだから，
絶対に他のマネージオブジェクトにアクセスしてはいけないし
余計な気をまわして他のオブジェクトのDisposeを呼ぶ必要もない
595:デフォルトの名無しさん
09/03/10 19:44:01
>>594
メモリの解放に限ってはそうだが、IDisposableは掴んでるリソースを解放するとか
最後にやらなければならないメソッドの総称という意味もあるので、
Disposeがあれば絶対に実行はすべき
596:594
09/03/10 19:55:03
すまんわかりにくかったね
Disposeしなくていい(してはいけない)というのはファイナライザ(デストラクタ)の中での話
クラスAがIDisposableなオブジェクトBをメンバに持ってるならA自身もIDisposableを実装して
A.Disposeの中でBをDisposeするようにしないといけない
その場合もファイナライザは不要
597:デフォルトの名無しさん
09/03/10 20:14:30
>>584
ローカルに保存したソースって、デバッグモード以外で直接見るにはどうすればいいんでしょうか。
598:デフォルトの名無しさん
09/03/10 20:15:03
WPFのExpanderのようなURLﾘﾝｸ(www.sociomedia.co.jp)
は C# .NET 2.0でも実装できますか？
599:デフォルトの名無しさん
09/03/10 20:32:35
>>597
.cs ファイルがあるから、直接見ればいいんでね？
600:デフォルトの名無しさん
09/03/10 20:39:16
>>599
あら、そんなのあったっけ。。。
確かめてみます。
601:デフォルトの名無しさん
09/03/10 21:34:01
>>595
＞Disposeがあれば絶対に実行はすべき
これは明らかに間違いだと思うが。
そう設計されているクラス（よくない設計だが）でもない限りは、
基本的にはGCに任せる方がいいとされる。
もちろん必要ならDisposeやCloseを呼んでもよい。
602:デフォルトの名無しさん
09/03/10 21:37:02
>>601
>このインターフェイスは主に、アンマネージ リソースを解放するために使用します。
>マネージオブジェクトが使用されなくなると、同オブジェクトに割り当てられているメモリは
>ガベージ コレクタによって自動的に解放されます。
>ただし、ガベージコレクションが行われるタイミングは特定できません。
>また、ガベージ コレクタでは、ウィンドウハンドル、開いたファイルやストリームなどの
>アンマネージ リソースが認識されません。
>ガベージ コレクタを使用して、明示的にアンマネージ リソースを解放するには
>このインターフェイスの Dispose メソッドを使用します。
>オブジェクトがもはや必要でない場合、オブジェクトのコンシューマはこのメソッドを呼び出します。
603:デフォルトの名無しさん
09/03/10 21:46:09
コピペ君って馬鹿だな、まで読んだ。
604:デフォルトの名無しさん
09/03/10 21:47:21
いやいやお前のほうがバカだろ
605:デフォルトの名無しさん
09/03/10 21:48:34
>>603
>このインターフェイスは、Disposeメソッドだけを定義している。
>使い終わったら確実に資源を解放する処理が必要なクラスは、
>このインターフェイスを実装して、解放処理を記述するのが.NET Frameworkでのお約束である。
606:デフォルトの名無しさん
09/03/10 21:52:11
内容が微妙だから揚げ足取りになりがちな話題だが、
>>601の言ってることの方が真実に近いよ。
馬鹿なコピペ君の負け。
馬鹿なコピペ君の言うとおりなら、例えばWindows Formのデザイナで
デザイン時にコンポーネントを貼り付けるような使い方をMSはわざわざ用意しないだろう。
607:デフォルトの名無しさん
09/03/10 21:54:33
>>602
そのどこにも「Disposeがあれば絶対に実行はすべき」
なんて書いてないよね。俺の言ってること分かってるかい？
明示的にDisposeやCloseを呼び出さなければ、
やがてGCがファイナライザを呼び出してアンマネージリソースの
後片付けをさせるってこと分かってるかい？
608:デフォルトの名無しさん
09/03/10 21:55:55
>>598
作ればできるでしょ
609:デフォルトの名無しさん
09/03/10 21:56:09
揚げ足取りもなにも、CLR via C# とか読めば普通に書いてあることだよね。
610:デフォルトの名無しさん
09/03/10 21:58:45
ともかく，必ず呼ばれることを期待した実装にしてはいけない
611:デフォルトの名無しさん
09/03/10 21:59:00
>>606
>>607
アンマネージ リソース＝ウィンドウハンドル、開いたファイルやストリームなど
IDisposableは主にアンマネージ リソースを解放するために使用
612:デフォルトの名無しさん
09/03/10 22:01:41
>>606
>馬鹿なコピペ君の言うとおりなら、例えばWindows Formのデザイナで
>デザイン時にコンポーネントを貼り付けるような使い方をMSはわざわざ用意しないだろう。
？？？
デザイン時にコンポーネントを貼り付けると自動的にDisposeが呼ばれるようになるけど
そういう話？
例えばボタンを貼り付けると、InitializeComponent()に
this.Controls.Add(this.button1);
みたいなのが追加される。
で、FormのDisposeでcomponents.Dispose();が呼ばれてる。
613:デフォルトの名無しさん
09/03/10 22:02:35
>>606
良く読もうな
>クラスで外部リソースを使用するが、そのクラスをデザイン領域では使用しない場合は、
>System.IDisposable を実装するか、あるいは直接または間接的に IDisposable を実装するクラスから派生させます。
>クラスがデザイン可能ではなく、外部リソースを保持していない場合は、IComponent 型や IDisposable 型は不要です。
614:デフォルトの名無しさん
09/03/10 22:05:39
>>611
別にIDisposableを実装していなくても、アンマネージリソースはファイナライザ中で解放すればいい。
IDisposableはGCに頼らずとも明示的にリソースを解放するための手段を与えるためのものだよ。
勘違いしているのでは？
615:デフォルトの名無しさん
09/03/10 22:05:58
>>612
話が通じない人だなあ。
言いたかったのは、もしIDisposable.Disposeが、不要になれば「必ず」呼ぶ必要があるほどの
緊急性があることを表すメソッドであるのなら、それを実装したクラスのインスタンスを
不要不急の時まで生かしておくことを許すようなことはしないだろう、
ということだよ。
まだ話が通じないとアレなので一応補足するけど、例えば
PrinterSettingDialogとかFileSaveDialogとか、いつもいるわけじゃないでしょ。
616:デフォルトの名無しさん
09/03/10 22:08:09
フォーム関連は生存期間が長いから少々無駄に長居してもそんなに問題にならない
617:615
09/03/10 22:09:30
あーなんかわけのわからんクラス名かいちゃったけど
PrintDialogとSaveFileDialogだなw
618:デフォルトの名無しさん
09/03/10 22:10:07
作る側と使う側じゃ、話もかみ合わないな・・・。
作る側は、必ず Dispose() を呼んでくれる、ってのを期待しちゃダメ。
使う側は、Dispose() を忘れちゃダメ。
619:デフォルトの名無しさん
09/03/10 22:13:53
>>615
>言いたかったのは、もしIDisposable.Disposeが、不要になれば「必ず」呼ぶ必要があるほどの
>緊急性があることを表すメソッドであるのなら、それを実装したクラスのインスタンスを
>不要不急の時まで生かしておくことを許すようなことはしないだろう、
>ということだよ。
ああ、「必ず」とつけた人がいてその人に噛みついていたのか。
それで「必要ではない」例をあげてたと。
しかしまあそれを言うなら>>601の
>もちろん必要ならDisposeやCloseを呼んでもよい。
こっちだって明らかに日本語が残念な人だろう。
「必要」な場面で「呼んでもよい」ってｗｗｗ
必要な場合は必ず呼べよｗｗｗ
620:デフォルトの名無しさん
09/03/10 22:14:17
>>615
換言すれば、そのソフトでfileを一度しかopenしないと考えられるのであれば
使い終わってもcloseする必要はないということですね
死ねば？
621:デフォルトの名無しさん
09/03/10 22:18:55
>>618
使う側も、作る側からDisposeの確実な呼び出しが期待されているのでもない限り、
「必ず」呼び出さなきゃいけないわけじゃないよ。
以下は CLR via C# の解説ね。
一応 .NET Frameworkの開発チームにも参加していた人の意見。
一般論として、筆者はDisposeメソッドやCloseメソッドの呼び出しを強制するのはあまり
推奨しません。CLRのガベージコレクタはとてもよくできているので、それに任せたほうが
いいからです。ガベージコレクタには、アプリケーションコードがオブジェクトにアクセスし
なくなるタイミングが分かっています。そしてそのタイミングが過ぎたときにだけ、オブジェクト
を回収します。アプリケーションコードでDisposeメソッドやCloseメソッドを呼び出すということは、
アプリケーションは自分がオブジェクトにアクセスする必要がなくなるタイミングが分かっている
と宣言をしていることになります。たいていのアプリケーションでは、オブジェクトが間違いなく
不要になったことがわかることはありません。
例えば、新しいオブジェクトを作成して、その参照を他のメソッドの引数に渡した場合、
そのメソッドが渡された参照を自分のオブジェクトの内部フィールド（これはルートになります）
に格納するかもしれません。メソッドを呼び出した側では、このような動作をしているかどうかは
分かりません。この場合、呼び出し側がDisposeやCloseを呼び出してしまって、その後で
他のコードがそのオブジェクトを利用しようとすると、ObjectDisposedExceptionがスローされる
ことになります。
筆者は、DisposeやCloseを自分のコードで呼び出すのは、次の2つの場合に限ることを
推奨します。１つは、リソースを解放しなければならないことが分かっている時（開いている
ファイルを削除しようとするときなど）です。もう１つは、DisposeまたはCloseを呼び出すことが
間違いなく安全で、しかもオブジェクトをファイナライゼーションリストから削除して、
オブジェクトが昇格するのを防ぐことで、パフォーマンスを向上させたい場合です。
622:デフォルトの名無しさん
09/03/10 22:20:36
>>619
IDisposableの目的が、主にアンマネージリソースの解放だから、
あれば実行するのは普通だと思うぞ？
この場合、ポトペタのコントロール等を持ち出して実行しなくてもいい例とするほうが狂ってる
623:デフォルトの名無しさん
09/03/10 22:23:10
>>621
大抵は最後の「2つの場合」に当てはまると思うんだけど
624:デフォルトの名無しさん
09/03/10 22:23:37
それはその人の意見に過ぎないでしょ。
> たいていのアプリケーションでは、オブジェクトが間違いなく
> 不要になったことがわかることはありません。
GC のない言語は全否定？ ありえないです。
アンマネージﾄﾞなリソースを使うから、それらのリソースを解放する
必要があるから、Dispose() を実装する。そう考えれば、Dispose() が
用意されてるなら、不要になった時点で呼ぶべきだと思うよ。
625:デフォルトの名無しさん
09/03/10 22:24:11
>>621
だから
>１つは、リソースを解放しなければならないことが分かっている時（開いているファイルを削除しようとするときなど）です
がDisposeの目的だって書いてあるっていってんの
626:デフォルトの名無しさん
09/03/10 22:24:18
>>618,>>619
だからさ、揚げ足取りのように聞こえるかもしれんがその「ダメ」とか「必要な場合は必ず」
っていう言い方は正しくないんだよ。
もっと控えめに、
(1) 占有している共有資源を他に譲りたいなら呼べ
(2) Disposeを呼ぶことをあえて避ける理由はなにもない
と表現するのが正しい。>>601の言っていることの方が妥当だ。
>>620
君はたぶん学生時代数学が出来なかった子だろうね。
君は必要条件と十分条件の区別がついてない。
Disposeを実装していることは、「使い終わったら必ず開放すべき資源を持っている」
ことの必要条件であっても十分条件じゃない。
つまり、Disposeを実装していることは、そのインスタンスが必ず
「使い終わったら必ず開放すべき資源を持っている」ことを意味しない。
627:デフォルトの名無しさん
09/03/10 22:24:19
>>621
それどこから引用したの？それとも自分で訳したの？
628:デフォルトの名無しさん
09/03/10 22:27:11
>>623
>>624
君たちのも「意見」に過ぎないよね。
しかも、素人の意見と、MSの多くのソフト開発に関わった人の意見とでは、
どちらを信用すべきか目に見ていると思うが。
（一応出版社もMicrosoftの書籍に書かれていることなので、
MSの準公式見解といっていい）
まともな人の書いた書籍で、絶対にDisposeを呼び出せって言ってるのはあるの？
それを提示しないと説得力ないよね。
629:デフォルトの名無しさん
09/03/10 22:27:41
>>626
君は今も理屈っぽいとよく他人からバカにされるでしょ。
Disposeの目的の主な利用方法がアンマネージリソースの解放なんだから、
できる時にしておくべき。
630:デフォルトの名無しさん
09/03/10 22:29:21
>>627
日本語版も「プログラミング .NET Framework」という題で出ている。
631:デフォルトの名無しさん
09/03/10 22:30:53
>>630
原著は持ってるが日本語版を持ってないから聞いたのだが。
632:デフォルトの名無しさん
09/03/10 22:30:54
こんがらがってきました
633:デフォルトの名無しさん
09/03/10 22:31:11
つーか、呼び出しても呼び出さなくてもいいなら、
安全面に倒して（リソース不足やらを引き起こさないように）
呼び出した方がいいじゃん。
そんなこともわかんないのかな・・・
634:デフォルトの名無しさん
09/03/10 22:31:28
>>628
良く嫁
>たいていのアプリケーションでは、オブジェクトが間違いなく不要になったことがわかることはありません。
だから
>一般論として、筆者はDisposeメソッドやCloseメソッドの呼び出しを強制するのはあまり推奨しません。
ってことだろ？
間違いなく不要になることはわからないから、一般的に推奨しないわけであって、
明らかに分かってる場合には、実行しても問題じゃないってこった。
従って、アンマネージリソースを抱えている可能性があるわけだから、
必要ないと分かっていれば実行はするべきだということになる。
635:デフォルトの名無しさん
09/03/10 22:32:09
なんか、原理主義者というか、細かいことにこだわる奴がいるなぁ・・・。
636:デフォルトの名無しさん
09/03/10 22:32:38
リソースをカプセル化したオブジェクトを使ったコードを記述する場合は、オブジェクトが不要になった時点で、
そのオブジェクトの Dispose メソッドが必ず呼び出されるようにする必要があります。
ついで
URLﾘﾝｸ(social.msdn.microsoft.com)
637:デフォルトの名無しさん
09/03/10 22:33:15
盲目的という感じはするね
> 明らかに分かってる場合には、実行しても問題じゃないってこった。
どう考えてもその通り
638:デフォルトの名無しさん
09/03/10 22:34:12
>>633
そこは誰も否定してないよ。
だから微妙な話だといってるんだけど。。
639:デフォルトの名無しさん
09/03/10 22:35:54
>>621の筆者が心配してるようなリソース行方不明状態は作るべきじゃないし
そういう状況は特別に注意して管理するべきであって一般にどうとかいう話じゃないと思うんだ
640:デフォルトの名無しさん
09/03/10 22:38:04
>>639
自分の書いたクラスだけを利用するとは限らないからなあ。
他人の書いたクラスを使う場合は防ぎようがないこともあるだろう。
641:デフォルトの名無しさん
09/03/10 22:40:36
つーか、言ってもない「必ず」とかの文言を勝手にでっち上げて
議論をふっかける奴って何なんだろう・・・？
642:デフォルトの名無しさん
09/03/10 22:42:15
「C++みたいに、メモリ解放とかしなくてもいいんですよ。
だから必ずDisposeさせようと思う必要はないんですよ？」
と過去の呪縛から解放させるためのトークが
「Disposeはすべきでない」
と理解されたらたまったもんじゃないな
643:デフォルトの名無しさん
09/03/10 22:42:49
まぁ、でも、コードレビューとかで「なんで Dispose() しないの？」って質問に
> つまり、Disposeを実装していることは、そのインスタンスが必ず
> 「使い終わったら必ず開放すべき資源を持っている」ことを意味しない。
とか答える奴とは一緒に仕事をしたくないな。
644:デフォルトの名無しさん
09/03/10 22:45:21
>>640
それ他人に書いたクラスにバグがありますと同じ
Disposeが信じられないのなら、他のメソッドの動作にも信頼がおかけないだろうから、自作するしかないね
645:デフォルトの名無しさん
09/03/10 22:45:31
>>641
じゃあ>>595にある、
>Disposeがあれば絶対に実行はすべき
の絶対と「必ずの違いをとっくりと説明してもらおうじゃないか。
というか、議論にすぐ感情を持ち込む君のような奴ははっきりいって議論の邪魔。
ついでにエンジニアの資格なし。
646:デフォルトの名無しさん
09/03/10 22:48:06
>>595=>>641 ってわけでもないだろうし、感情的になってるのは
どっちもどっちじゃない？
647:デフォルトの名無しさん
09/03/10 22:50:44
>>645
そうやって論議を他の方向にそらしたい気持ちはわかるが、
Disposeは絶対に必ず間違いなく確実に死んでも実行すべき
もちろん必要なくなったらの話
648:デフォルトの名無しさん
09/03/10 22:55:14
>>647
別に明示的にDispose()を呼ばなくても、ガベコレが動けば、FinalizeがDispose(bool disposing)の方を呼ぶでしょ。
これもDisposeメソッドだから（というより本体）、結局のところDisposeは確実に呼ばれるんだよね〜。
そういう意味では、Disposeメソッドは絶対に呼ばれるべきだし、また通常はそうなっているだろう。
649:デフォルトの名無しさん
09/03/10 22:57:42
むやみやたらに GC.Collect() するようなコードをたまに見かけるな・・・
そんなのよりは、よっぽど Dispose() を呼び出す方がましな気がする。
650:デフォルトの名無しさん
09/03/10 22:57:44
Disposeが必要なのは結局のところタイミングの重要なのであって、
その意味で>>648の発言は基本がまったく理解できてない
651:デフォルトの名無しさん
09/03/10 22:59:51
わかりやすくいうとこんな感じ
■Disposeしなくてもいいよ派
手洗いをしていないからといって、必ずしもインフルエンザにかかるとは限りません。
手洗い場には人が殺到するので、余計にインフルエンザにかかるリスクが増加します。
■Disposeしたほうがいいよ派
手洗いをしたほうが手からの感染が少なくなるのでしたほうがいいに決まっています。
混雑した場などに出かけた場合の話をしているのであって、
その場合には手を洗ったほうが感染のリスクが低下します。
652:デフォルトの名無しさん
09/03/10 23:00:38
>>650
Disposeを確実に呼び出すように（あるいは呼び出されるように）しろ、
と言ってる記述があっても、それは広義のDisposeメソッド（bool型を引数に取るような）
を指しているのかもしれんから、必ずDispose()を呼べと言っているのか断定しがたいってことだよ。
653:デフォルトの名無しさん
09/03/10 23:01:06
>>651
結論
人がいないときに（必要でなくなったら）必ず手洗いしましょう（必ずDisposeしましょう）
654:デフォルトの名無しさん
09/03/10 23:03:28
>>652
Disposeの実装の主な理由が、必ず実行されるべきアンマネージリソースの解放にあるんだから、
必要なくなったら必ず実装するべきってことだよ
あなたが、必要ないかどうかわからない糞設計をしているのなら、
あなたが断定できないから実行できないということに関しては同意する
655:デフォルトの名無しさん
09/03/10 23:04:26
>>651
だから違うよ。
わかりやすく、とか言ってる奴が話の筋が読めないってなんの笑い話？
あるクラスがDisposeを実装してるからといって、
必ずしも「必ず」使い終わったら呼ぶ必要があるとは限らないって話だよ。
必ず呼ぶべきクラスもあれば、そうでないクラスもあるってこと。
この程度の簡単な話が理解できない人間はプログラマやってちゃあかんと思うなあ。
656:デフォルトの名無しさん
09/03/10 23:05:12
>>654
必要ないかどうか分からない糞設計とか言い出したら、ガベコレ自体否定している。
そして明示的にマネージオブジェクトを解放できないC#を否定していることになる。
657:デフォルトの名無しさん
09/03/10 23:07:05
>>655
呼ぶ必要がある、ない、ってのはどうやって判断するの？
658:デフォルトの名無しさん
09/03/10 23:09:46
明示的にDisposeで解放しなくとも、オブジェクトが確実に必要なくなれば、
ガベージコレクタによって保有するリソースは解放されるだろう。
少なくともFCLのクラスは、そこまで待っていても不具合はないだろ。
メモリが惜しけりゃ明示的に呼び出せってだけのことなのでは？
659:デフォルトの名無しさん
09/03/10 23:10:26
>>655
自分が作成したインスタンスで、そのインスタンスが役目を終えたと判断できたら
Disposeしましょうってことを言ってるんじゃん。
話の流れを読めてないのはお前でしょ
660:デフォルトの名無しさん
09/03/10 23:10:35
お前ら楽しそうだけど、(初心者用)で盛り上がるネタじゃないと思うんだ
661:デフォルトの名無しさん
09/03/10 23:11:08
言葉が抜けてて誤解を招きかねないので訂正
ガベージコレクタによって「Finalize、そしてDispose(bool)が呼ばれた結果」保有するリソースは解放されるだろう。
662:デフォルトの名無しさん
09/03/10 23:11:37
かなり前に、GotDotNet で盛り上がったネタだしね。
663:デフォルトの名無しさん
09/03/10 23:12:07
>>657
MSDNライブラリ+常識
だから、明示的にDisposeすべきかどうかはそのクラスが占有している
共有資源がどの程度希少かという問題と同義で、そんなことは常識でだいたい
わかるじゃん。
664:デフォルトの名無しさん
09/03/10 23:13:25
>>659
だから、そのテーゼは常に真ではない、という話をずっとしてるんだがな。
悪気はないけど、君はこういう話題をするには頭が悪すぎるみたいだねw
665:デフォルトの名無しさん
09/03/10 23:13:58
>>656
あたまの悪い人だなぁ
>必要ないかどうか分からない糞設計とか言い出したら、ガベコレ自体否定している。
>そして明示的にマネージオブジェクトを解放できないC#を否定していることになる。
アンマネージリソースの解放って言ってるのに、なんでカベコレそのものの否定とかの話になんの？
FileをOpenして、Closeするまでガベコレの動作を待てってどんなソフトなの？
666:デフォルトの名無しさん
09/03/10 23:14:12
>>663
ぽかーん・・・
そんな各開発者で異なりそうな基準なら、安全側に倒して、
必ず Dispose() すること、って規約にするよ。
667:デフォルトの名無しさん
09/03/10 23:15:02
>>664
常に真ではないが、ほとんど真だ、という話をずっとしてるんだがな。
悪気はないけど、君はこういう話題をするには頭が悪すぎるみたいだねw
668:デフォルトの名無しさん
09/03/10 23:18:12
>>665
そのファイルを開きっぱなしであることが、
色々な意味でコストがかかるなら、明示的にCloseするだけでしょ。
そうでなく、しかも閉じる必要がなきゃ、別に放置しておいても問題ない。
必要かどうかの管理をプログラマに強いるのはC#の思想じゃないでしょ。
CやC++ならそういう態度でいいけど、C#じゃ基本的にガベコレ任せだ。
アンマネージリソースについては凄く敏感なようだけど、マネージリソースについては何も思わないの？
ガベコレが動くまでメモリを占有し続けたままって。
そういうのが気になるならC++とかやってりゃいいのでは？
669:デフォルトの名無しさん
09/03/10 23:19:12
確かに、Dispose() で何もしないクラスは存在する。
が、IDisposable() インターフェイスがアンマネージドリソースの解放目的に用意されている以上、
Dispose() メソッドを実装してるなら、それを呼ぶ必要があるってケースの方が多いだろうね。
670:デフォルトの名無しさん
09/03/10 23:19:53
>>666
それはそれでいいんじゃないの？
それと今の話は別問題だよ。わかるよね？
671:デフォルトの名無しさん
09/03/10 23:22:09
>>670
イレギュラーケースをたてに、Dispose() を呼ばなくてもいい、って
言い張ってる奴がいる、ってのは理解してます。
672:デフォルトの名無しさん
09/03/10 23:22:21
>>668
>色々な意味でコストがかかるなら、明示的にCloseするだけでしょ。
必要なくなったら閉じるのが当たり前でしょ。
必要なときに閉じないのは当たり前でしょ。
何言ってるの？
>アンマネージリソースについては凄く敏感なようだけど、マネージリソースについては何も思わないの？
Disposeの実装の主な理由がアンマネージリソースの解放にあるんだから、
アンマネージリソースについて語るのは当たり前でしょ。
673:デフォルトの名無しさん
09/03/10 23:23:19
GC なしの C#、あったら使ってみたいなぁ。
674:デフォルトの名無しさん
09/03/10 23:24:12
>>670
なんで？
どこでオブジェクトが再利用されるかわからないから、
Disposeすべきなんじゃなかったの？
だんだん主張がおかしくなってきていますな
675:デフォルトの名無しさん
09/03/10 23:24:24
>>671
だからそんなことを言ってる奴はいなんだよ。
頭の悪い奴は議論に参加しなくてよろしい。
676:デフォルトの名無しさん
09/03/10 23:25:39
>>674
訂正
>どこでオブジェクトが再利用されるかわからないから、
>Disposeするべきでないんじゃなかったの？
>>621の解釈よりｗ
677:デフォルトの名無しさん
09/03/10 23:25:51
>>672
だから、Dispose()を明示的に呼ばずとも、結局、
最終的にFinalize経由でリソースの解放は行われる。
結局のところタイミングの問題だけでしょ。
Disposeを絶対呼べ、って言ってるぐらいメモリ資源に敏感なのに、
明示的解放のできないマネージリソースは完全にGC任せのC#を使っているのは何故かなあって思うんだが。
678:デフォルトの名無しさん
09/03/10 23:27:57
アンマネージドリソース = メモリ
と間違った理解をしてるのもどうかと思うけどな・・・
679:デフォルトの名無しさん
09/03/10 23:28:17
>>674
今の話題はDisposeを実装しているクラスは必ずDisposeすべきか。
俺の意見は否だけど、だからといって「必ずDisposeを呼べ」という規約が
ナンセンスとは断定できない。
例えばC#のコンパイラにとってはインデントは無視するだけの存在の「いらない子」だけど、
だからといって「ちゃんとインデントしろなんて規約はナンセンスだ」なんて
誰も言わんでしょ。
それとこれとは別問題だから。
680:デフォルトの名無しさん
09/03/10 23:29:08
>>675
じゃあ、どこに問題があるか個別に○×つけてくれよ
１ IDisposableは主に、アンマネージ リソースを解放するために使用する
２ アンマネージリソース(File Openなど)を所有していた場合、必要なくなったら解放する必要がある。
３ 必要がなくなったらDisposeを実行してリソースを解放すべき
どこがおかしい？
681:デフォルトの名無しさん
09/03/10 23:29:31
>>675
Finalize が呼んでくれるから、Dispose() は明示的に呼ばなくてもいいんじゃないの？
682:デフォルトの名無しさん
09/03/10 23:30:29
まとめ
IDisposableを実装するクラスに求められる最低限度の機能は、
好きなタイミングで明示的にDispose()を呼び出して、アンマネージリソースを解放するということだけ。
この最低限度の実装しかしていないクラスなら、Dispose()は絶対に呼ばなきゃいけない。
でもこれじゃ、もしDispose()を呼び出すのを忘れた場合に、
アンマネージリソースは解放されずに残ってしまう。
そこで安全弁として、まともなクラス（FCLなど）では、
Finalize経由でもDispose(bool disposing)を呼び出してリソースの解放が行われるようになっている。
そういうクラスでは別に明示的にDispose()を絶対に呼び出さなきゃいけないわけではない。
683:デフォルトの名無しさん
09/03/10 23:32:23
超初心者ですいません
visual C♯をやっててコンボボックスの規定値？を表示させるにはどうしたらいいんですか？
普通コンボボックスはドロップダウンのリストから文字を選んだらそれが表示されると思うんですが、
ドロップダウンリストから選ぶ前から既定の文字を表示させておきたいんですがどうやればいいんでしょうか？
それとコンボボックスで選んだものによってボタンを押したときの処理を分けるにはどうしたらいいんですか？
説明分かりづらすぎですいません
684:デフォルトの名無しさん
09/03/10 23:33:07
∧∧ ∩
(｀･ω･´)/
ﾊ_ﾊ ⊂ ﾉ ﾊ_ﾊ
('(･ω･´∩ (つ ﾉ ∩｀･ω･)')
ﾊ_ﾊ ヽ 〈 (ノ 〉 / ﾊ_ﾊ
('(･ω･´∩ ヽヽ_) (_ノ ノ ∩｀･ω･)')
O,_ 〈 〉 ,_O
｀ヽ_) （_/ ´
ﾊ_ﾊ 知 ら ん が な ﾊ_ﾊ
⊂(･ω･´⊂⌒｀⊃ ⊂´⌒⊃｀･ω･) ⊃
685:デフォルトの名無しさん
09/03/10 23:34:13
>>683
SelectedIndex を設定 or 読み取り
686:デフォルトの名無しさん
09/03/10 23:35:13
>>682
矛盾してるぞ？
>IDisposableを実装するクラスに求められる最低限度の機能は、
>好きなタイミングで明示的にDispose()を呼び出して、アンマネージリソースを解放するということだけ。
>この最低限度の実装しかしていないクラスなら、Dispose()は絶対に呼ばなきゃいけない。
IDisposableを実装していれば、いつかはDisposeは実行されるんだろ？
その理屈なら呼ぶ必要なんてないじゃん
687:デフォルトの名無しさん
09/03/10 23:35:32
>>682
つーか、そんなのはみんなわかってて、「で、どうすべきか？」って話をしてると思うんだけど。
必要あるかないかが内部実装に依存する以上、呼び出すべきって意見と、
Finalize で呼び出されるんだから、別に呼び出さなくてもいい、って意見だろ。
688:デフォルトの名無しさん
09/03/10 23:36:07
>>682
返答よろしく
１ IDisposableは主に、アンマネージ リソースを解放するために使用する
２ アンマネージリソース(File Openなど)を所有していた場合、必要なくなったら解放する必要がある。
３ 必要がなくなったらDisposeを実行してリソースを解放すべき
どこがおかしい？
689:デフォルトの名無しさん
09/03/10 23:38:12
>>688
俺は Dispose() するべき派だから、どこも間違ってない（正しい）と思います。
690:デフォルトの名無しさん
09/03/10 23:39:55
>>682
>そこで安全弁として、まともなクラス（FCLなど）では、
>Finalize経由でもDispose(bool disposing)を呼び出してリソースの解放が行われるようになっている。
>そういうクラスでは別に明示的にDispose()を絶対に呼び出さなきゃいけないわけではない。
こういうケースもあるから一概にそうとも言えないと思うがな。
StreamWriterのFlush/Close/Disposeを呼ばない場合
書き込みキャッシュの内容がフラッシュされないので内容がロストする。
ファイルは確かにクローズされるんだけど。
もちろんStreamWriterにはDispose(bool disposing)があるぜ。
URLﾘﾝｸ(msdn.microsoft.com)
static class Program
{
static void Main(string[] args)
{
var sw = new StreamWriter(@"c:\test.txt");
sw.Write("A");
}
}
Disposeに関してはもはやアンマネージリソースかどうかに拘っても意味がない気がする。
アンマネージリソースが解放されずに残るわけじゃないとはいえ
このケースでDisposeを呼ばなくて良いと言うのは無理がありすぎる。
691:デフォルトの名無しさん
09/03/10 23:41:29
どのオブジェクトがどれだけアンマネージリソースでメモリ圧迫してるかなんて
GCには全くわからないんだよ
GC.AddMemoryPreassureなんて極めてチープな機能があるくらい
692:デフォルトの名無しさん
09/03/10 23:41:54
>>686
違うだろ。IDisposableを実装しているだけじゃ、Disposeが絶対に呼び出されるとは限らない。
例えば自分で作ったクラスでIDisposableを実装して、Finalizeでリソース解放処理をしなければそのまま残る。
しかしFCLやそれに準拠した規範的なクラスでは、確実にFinalize経由でリソース解放されるようになっている。
そういうクラスを使うのであれば、別にDispose()を絶対呼び出す必要があるとまではいえない。
そうでないクラスであり、Finalize経由での解放が保証されていないのであれば、Dispose()は絶対に呼び出すべき。
>>688
別におかしくはないよ。でもそれはIDisposableの「最低限度の実装」をしたクラスについてだよね。
でも実際にIDisposableを実装したクラスは、それ以上の実装をしているのが普通なわけ。
まあ本音と建前みたいなもんだな。
693:デフォルトの名無しさん
09/03/10 23:43:27
言い争ってる奴ら馬鹿だろ。少しは落ち着けよ
694:デフォルトの名無しさん
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
＞通常遅くは無い。
これが間違い
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5384日前に更新/246 KB
担当:undef