09/03/08 23:59:18
main()があるクラスの名前ってどうしてる？
IDEの吐くスケルトンのデフォのProgramのままが普通なんだろうか。
あと、グローバルなシングルトンを取得する静的メソッドを寄せ集めたクラスって
定番の名前とかあるのかな。
504:デフォルトの名無しさん
09/03/09 00:01:24
どっちも絶対にinternalにするので名前なんてどうでもいい
505:デフォルトの名無しさん
09/03/09 00:05:15
>>503
クラス名・変数名に迷ったら書き込むスレ。Part14
ｽﾚﾘﾝｸ(tech板)l50
506:デフォルトの名無しさん
09/03/09 00:06:35
>>505
なにこの俺にぴったりのスレ。
507:デフォルトの名無しさん
09/03/09 00:21:07
>>504
コードを書く人にとってはそうでも、コードを読む人（3ヶ月後の自分を含む）
にとってはそういう考え方は困る。
少なくとも普通はクラスファイルが数十以上になる、
ある程度実用的なコードを書いてる場合は。
前にも書いたけど、やっぱり2chってトリビアルな知識はなぜか妙に詳しいが
大きなプログラムは書いたことないし書けない人間が多いのかな。
508:デフォルトの名無しさん
09/03/09 00:22:48
最後の2行がなければ全面的に同意したのに
509:デフォルトの名無しさん
09/03/09 00:25:42
大きいの作るときにグローバルインスタンス寄せ集めクラスはそもそもどうかと
510:デフォルトの名無しさん
09/03/09 00:57:31
>>507
個人的には C# だと名前変えるのそんなに大変じゃない場合が
多いから >>504 とは別の理由で結構無頓着だなぁ
名前ってウダウダ考えるより書いてないときにひょんと来たり
整理してから思いついたりするから後回しにしてそういう時間を
とるほうを優先するかな。
511:デフォルトの名無しさん
09/03/09 09:40:54
どうでもいいというのは、その状況で適切な名前をつければいいと言うことであるわけで
何か固定の名前を付けるなんて小規模で1人でやってる場合ならいいが
512:デフォルトの名無しさん
09/03/09 16:55:32
C#からFlashをocxで呼び出して表示させると、
Microsoft OEM Readyプログラムのテスト5で
バッファーアンダーランのようなエラーで止まってしまうんですが、
何か良い方法はないのでしょうか。
FlashはAS2とAS3で、それぞれステージだけある空のswfファイルです。
---
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\Macromed\Flash\Flash10b.ocx -
Flash10b+0x3ef4a:
673fef4a 8a08 mov cl,byte ptr [eax] ds:0023:11012000=??
513:デフォルトの名無しさん
09/03/09 17:42:59
rubyでMechanize使って実装していた処理をC#に移植中なんですが
「Webページのテキストボックスに文字列を入力してsubmitボタンを押す」
というような処理をするときWebBrowserクラスを使うしかないんでしょうか
できればDocumentCompleteで待つように別スレッドが発生しないクラスがあればうれしいのですが・・・
514:デフォルトの名無しさん
09/03/09 17:49:00
多分IronRubyとか使ってRubyのを使えるだけそのまま使った方がいい
515:デフォルトの名無しさん
09/03/09 17:50:47
なんでC#なんだろ
516:デフォルトの名無しさん
09/03/09 18:38:40
Linqについて勉強しようと思っているのですが、何かお薦めの本があれば教えてください
517:デフォルトの名無しさん
09/03/09 19:13:43
もしかしたら、.NET Frameworkのバグ（？）を見つけたかもしれないんですが、
本物か勘違いか、皆さんのご意見を伺いたいです。まずはサンプルコードを。
-----------------------
Type type = typeof(List<string>); // 型は何でもいいです
type.GetInterfaces(); // .NET Framework 1.1以降のメソッド
type.GetGenericArguments(); // 2.0以降のメソッド
Type delegator = new TypeDelegator(type);
delegator.GetInterfaces(); // 無問題
delegator.GetGenericArguments(); // NotSupportedExceptionをthrow
type.Equals((object)delegator); // false <= ???
type.Equals((Type)delegator); // true
delegator.Equals((object)type); // true
delegator.Equals((Type)type); // true
-----------------------
解説は次のレスで。
518:デフォルトの名無しさん
09/03/09 19:16:00
勘違い
以上
519:デフォルトの名無しさん
09/03/09 19:25:00
URLﾘﾝｸ(msdn.microsoft.com)
> TypeDelegator クラス
> Type オブジェクトをラップし、すべてのメソッドをこの型にデリゲートします。
という継承用のヘルパークラスなんですが、以下の二点について。
(1) Typeクラスのメソッドのうち、.NET 2.0以降でサポートされたメソッドをサポートしていない？
きちんと確かめたわけではないのですが、TypeDelegatorでは.NET 1.1の時点で
Typeがサポートしていたメソッド以外について委譲（デリゲート）を実装していないように見えます。
通常は、Type.GetGenericArguments()を呼ぶと、実行時にはSystem.RuntimeTypeの実装を呼ぶので
問題ないのですが、TypeDelegatorから呼ぶと、継承元のメソッドであるType.GetGenericArguments()
が呼ばれます
また、SSCLIにあるコードによれば、Typeでの実装は
URLﾘﾝｸ(labs.developerfusion.co.uk)
> public virtual Type[] GetGenericArguments()
> {
> throw new NotSupportedException(Environment.GetResourceString("NotSupported_SubclassOverride"));
> }
となっているらしいので、TypeDelegator.GetGenericArguments()を呼ぶと
NotSupportedException（「派生クラスには実装を指定しなければなりません。」）が投げられてしまうようです。
520:デフォルトの名無しさん
09/03/09 19:38:51
ジェネリクスでも、メソッドの引数としてType typeof(T)を渡すとSystem.RuntimeTypeが渡されるけど
同じ場所でtypeof(T).ToString()を渡すとTのクラス名が渡される
なぜだ？
坊やだからさ
521:デフォルトの名無しさん
09/03/09 19:39:16
(2) Type.Equals((object)TypeDelegator)の判定が正常でない？
Type.Equals(object)の方を呼んでTypeDelegatorのインスタンスを渡した場合のみ、
同じTypeを指していてもfalseが戻るようです。
こちらは原因がさっぱり分かりませんが、正常な判定ではないような気がします。
---------------------
というのが私の意見なのですが、勘違いぽかったらツッコミをお願いします。
522:デフォルトの名無しさん
09/03/09 19:48:26
>>520
すいません、もう少し詳しくお願いします。
523:デフォルトの名無しさん
09/03/09 20:04:35
とあるジェネリクスメソッドGeneticMethod<Nullpo>内で
public void Method(Type type)としてMethod(typeof(T))とすると、
MethodにはSystem.RuntimeTypeが渡される
同じジェネリクスメソッド内から
public voix Method(string typeName)としてMethod(typeof(T).ToString())とすると、
Methodには、Nullpoが渡される
524:デフォルトの名無しさん
09/03/09 20:11:34
>>523
申し訳ない、その場合どこが問題なのか分からないです。。
525:デフォルトの名無しさん
09/03/09 20:18:10
引数として渡しているのは、同じNullpoなのに、片方はなぜかSystem.RuntimeTypeが返るんだぜ
なぜだ
526:デフォルトの名無しさん
09/03/09 20:59:00
.NET版のwikipediaってないですか？
C#とMSDEとかで作られてるやつ。
社内のシステムに取り入れたいんです。
527:デフォルトの名無しさん
09/03/09 21:04:23
>>526
Wikipedia はないだろ。Wiki はあるけど。
528:デフォルトの名無しさん
09/03/09 21:10:32
>>527
wikiを教えてください。
529:デフォルトの名無しさん
09/03/09 21:17:58
ぐぐったら 三番目にでてきた
URLﾘﾝｸ(csharp-source.net)
DotNetNuke(DNN) にも、Wiki の機能はあったはず。
530:デフォルトの名無しさん
09/03/09 21:24:08
>>525
typeof(T)がSystem.RuntimeTypeなのは、もちろん当然ですよね。
typeof(T).ToString()がstringなのも、やはり当然ですよね。
具体的に、どの辺が問題だというお話なんでしょう？
531:513
09/03/09 21:27:58
>514 >515
.NETの機能を使えと上に言われて組んでる感じです
何でなのかは・・・よくわかりません・・・ｗ
このレスの感じだとWebBrowser使うしかな下げな感じですかね
レスポンスありがとうございました
532:デフォルトの名無しさん
09/03/09 21:29:13
>>530
typeof(T).ToString()はstringだけどNullpoだって
typeof(T)をTypeとして渡してType(T).ToString()がSystem.RuntimeTypeなら、
typeof(T).ToString()がSystem.RuntimeTypeでないのはなんでだぜ？
533:デフォルトの名無しさん
09/03/09 21:39:39
>>531
ううん。
HttpWebRequest でリクエストして、結果を受け取って、
さらに Post する。
atmarkIT とかにサンプルあるよ。
534:デフォルトの名無しさん
09/03/09 21:41:48
話がかみ合ってないんだから、へんなたとえ話するのやめろよ
535:デフォルトの名無しさん
09/03/09 21:43:19
>>531
WebBrowserはGUIありきなので表示しないのなら使うべきでない
標準ライブラリにはスクレイピング用ライブラリは存在してない
自前で実装するかCodeProjectあたりから拾うかしないと駄目だな
あ、IEを非表示で使う？ でもIE7から面倒になったような気がする
536:デフォルトの名無しさん
09/03/09 21:49:42
URLﾘﾝｸ(www.atmarkit.co.jp)
基本はこの辺かな？
537:デフォルトの名無しさん
09/03/09 21:50:16
>>532
private static void GenericMethod<T>()
{
Method(typeof(T));
Method(typeof(T).ToString());
}
private static void Method(Type type)
{
Console.WriteLine(type);
}
private static void Method(string type)
{
Console.WriteLine(type);
}
GenericMethod<Nullpo>() の出力結果：
Nullpo
Nullpo
538:デフォルトの名無しさん
09/03/09 22:17:06
>>537
パソコンから「ガッ」って音がしました！
539:デフォルトの名無しさん
09/03/09 22:21:04
>>537
いやいや
private void Method<T>()
540:デフォルトの名無しさん
09/03/09 22:21:26
>>537
まだ私が何かわかってないのかもしれませんが、
Type型インスタンスをstring型の引数に渡したら、暗黙にToString()が呼ばれる以上、
両方とも"Nullpo"というstring型インスタンスとしてWriteLine()に渡るのは、
特に不思議ではないのでは。
私が>>517-521で疑問視しているのは、Type型のスーパークラスであるobject型を引数に取る、
Equals(Type)のオーバーロードであるEquals(object)の結果が、Type型のそれと異なっている
のは不自然だし、そもそもEquals()の常識的に考えられる結果と齟齬しているのではないか、
ということなのですが。
541:デフォルトの名無しさん
09/03/09 22:32:15
>Type型インスタンスをstring型の引数に渡したら、暗黙にToString()が呼ばれる以上
呼ばれません。WriteLineの引数の型はobject型で中でToStringを呼んでます。
542:デフォルトの名無しさん
09/03/09 22:40:03
コネクションプーリングってやつはado.netが勝手にやってくれるもんなんすか？
プログラムでは、DBに接続してSQL発行して切断するというロジックを組んでも
内部的には切断されずに次の処理のためにセッションを保持しててくれるの？？
543:デフォルトの名無しさん
09/03/09 22:41:51
RuntimeTypeがType.Equals(Object)の実装をオーバーライドして
単純な参照比較に変更してるのが原因みたい
どう考えても明確な意図があってやってると思われるのでたぶん仕様なんだろう
544:デフォルトの名無しさん
09/03/09 22:46:23
>>542
はい。設定は、接続文字列でやります。
545:デフォルトの名無しさん
09/03/09 23:01:38
>type.Equals((object)delegator); // false <= ???…(1)
>type.Equals((Type)delegator); // true…(2)
>delegator.Equals((object)type); // true…(3)
(1)と(2)はともかく，(1)と(3)で結果が違うのはObject.Equalsの要求仕様に反してるね
だけど今更こんな基礎的なとこを変えるのはありえないので仕様と考えるしかないな
546:デフォルトの名無しさん
09/03/09 23:17:48
動的にイベントを追加するときに
もう既に追加されているかどうか確認してから
追加されてないときだけ、イベントを追加したいのだけど
どうすればいいのですか？
547:デフォルトの名無しさん
09/03/09 23:18:08
２ちゃんねる風の掲示板で.net版ってありますか？
548:デフォルトの名無しさん
09/03/09 23:18:48
>>541
なるほど。
どちらにせよ、該当メソッドの実装意図から考えても不自然な挙動ではないように思います。
>>543
>>545
確かに、これは仕様と考えて対処した方が良さそうですね。
いちおう、TypeDelegatorの件(>>517)も気になるので合わせて報告しておきたいのですが、
こういうのってどこに報告すればよいんでしょうか。
549:デフォルトの名無しさん
09/03/09 23:37:06
>>546
直接には無理。追加したらフラグ立てとくしかない。
イベントというのはそういうもの。
>>548
いやTypeDelegatorは継承して必要なメソッドをオーバーライドするものなので
好きにオーバーライドして使えということだろ
NotSupportedExceptionを投げるのが既定の実装なんだから何もおかしくない
550:デフォルトの名無しさん
09/03/09 23:45:09
TypeDelegatorってTypeの派生クラス作るときにabstractメンバ全部実装するの面倒だから
既定の丸投げ実装を提供してるだけなんだと思う
GetGenericParametersはabstractじゃないんだから当然そのまま
GetGenericParametersに限らずTypeの他のvirtualメンバもTypeDelegatorでは実装されてない
551:550
09/03/09 23:46:01
GetGenericArgumentsだった
552:デフォルトの名無しさん
09/03/09 23:46:13
>>517
これって、type.Equals()はRuntimeType.Equals()を呼んでいて、delegator.Equals()はType.Equals()を呼んでるから
結果が違うんじゃないの?
RuntimeType.Equals()は
obj == this
だし、Type.Equals()はUnderlyingSystemTypeを比較してるみたいだけど。
TypeDelegatorのUnderlyingSystemTypeはコンストラクタで代入したTypeのインスタンスのUnderlyingSystemTypeを
返してるみたい。
>>545
>Object.Equalsの要求仕様
今まで特に気にして無くて初めて知ったので読んでみたい。詳細ｷﾎﾞﾝ
553:デフォルトの名無しさん
09/03/09 23:50:24
>>549
確かにそれも一理あると思います。
ただ、ドキュメントの一行目に
Type オブジェクトをラップし、『すべての』メソッドをこの型にデリゲートします。
と書いてあるわけで、実際には委譲されないメソッドが存在するのは、
ドキュメントを読んだライブラリ利用者が期待する挙動に即しているとはいえないのでは。
554:デフォルトの名無しさん
09/03/09 23:52:09
>>552
MSDNのObject.Equalsのページに載ってる
>>553
そういうのは九割九分ドキュメントの方が悪いw
よくあること
555:デフォルトの名無しさん
09/03/09 23:55:44
>>546
別に重複して登録されたりはしないよ。
556:デフォルトの名無しさん
09/03/10 00:00:24
重複して登録されるよ。
557:555
09/03/10 00:02:27
試してみたら重複して登録される...orz。
558:555
09/03/10 00:05:30
ちょうどObject.Equalsの話が出ているのでついでに書いておくと
デリゲートってインスタンスが違くても参照先のメソッドが等しければ
等価って判定されるんだよね。いわゆる値比較ってやつ。
だから、イベントの登録、削除もそれを反映していると勘違いしていた...orz.
559:デフォルトの名無しさん
09/03/10 00:05:40
>>552
どうもそういうことみたいですね。
>>554
これのせいで２～３日潰した方としてはかなり文句が言いたい感じですがｗ
むぅ～
560:デフォルトの名無しさん
09/03/10 00:12:39
>>554
thx
今回引っかかってるのは
・x.Equals(y) は y.Equals(x) と同じ値を戻します。
ってやつか。
561:デフォルトの名無しさん
09/03/10 03:16:14
>>546
remove して add すればいい
562:デフォルトの名無しさん
09/03/10 07:13:11
+=は？
563:デフォルトの名無しさん
09/03/10 07:53:07
>>546
どこで追加したかわかってないような設計をまずやめろ
564:513
09/03/10 09:04:58
>533 >535-536
遅くなったけど ありがトン
勉強してみます
565:デフォルトの名無しさん
09/03/10 10:06:00
デリゲートが理解できずに苦しんでるんだけど、
昔のvbでいうと、evaluate関数みたいな使い方ができるってこと？
566:デフォルトの名無しさん
09/03/10 10:16:56
うんにゃ
567:デフォルトの名無しさん
09/03/10 10:17:25
URLﾘﾝｸ(up2.viploader.net)
自宅にあるVS2008expressから別パソコンにソリューションファイルを移して
これまたVs2008expressで起動したんだけど
こういう表示がでて、上手くプログラムが動かないんだが・・・。
具体的にはgmailのサーバーにつなげるセッションが完了しない。
解決法ご存じの方いますか。
568:567
09/03/10 10:18:26
あ、言い忘れてました。
ソースファイルのパスは自宅パソコンのパスになってるので
このパスを実行パソコンのソリューションファイルのパスに変更できれば
直るのかなーと思っているんだけど・・・。
569:デフォルトの名無しさん
09/03/10 10:20:31
Mail.csを追加するときに「リンクとして追加」やってない?
普通にプロジェクトに追加しないと
570:567
09/03/10 10:21:30
あああ・・・すみません。
もう一つ言い忘れが。
自宅のPCはVistaで.slnを移動して実行しようとしている環境はXPです。
571:デフォルトの名無しさん
09/03/10 10:22:22
リビルドしたか?
572:デフォルトの名無しさん
09/03/10 10:23:27
>>567
ソリューションのプロパティ→構成プロパティ→構成
でビルドすべきプロジェクトにチェック入ってる？
573:567
09/03/10 10:27:18
>>569
早速の解答ありがとうございます。
slnファイルから起動しているので
既にプロジェクトに組み込まれている感じなんですが・・・。
ソリューションエクスプローラー上にもファイルの表示がされているし
Mail.csのプロパティの完全パスっていう項目も
現在のＰＣのパスになっているから、問題はなさそうなんですが。
一応既存の項目の追加でもう一度Mail.csを読み込んでみましたが
改善はないようです・・・。
574:567
09/03/10 10:33:30
>>571
デバッグ実行時にMainFormは開けているので、
リビルドというか、ビルド自体は出来てると思うんですが
エラーウィンドウをみる限り、Mail.csを上手く読み込めてない感じかなあ？
>>572
ソリューションのプロパティには
・スタートアッププロジェクト
・プロジェクト依存関係
・デバッグソースファイル
の3項目しか表示されてないんですが
これは自分のＩＤＥがExpressだからでしょうか・・・。
575:567
09/03/10 10:43:44
うーん・・・
これは現在のＰＣのネット環境の問題かも知れないですね。
自宅ではGmailに接続できるのに、現在のＰＣでは接続できないぽ・・・。
メール関連のライブラリはTKMPって奴を使ってるんですけど
こういう現象って起こりうる物でしょうか。
576:デフォルトの名無しさん
09/03/10 10:55:02
>>574
かも。572はPro版を見て言った。
Proでソリューションのプロパティはこうなってる。
→共通プロパティ
→スタートアッププロジェクト
→プロジェクト依存関係
→デバッグソースファイル
→構成プロパティ
→構成
てか「ビルド」メニュー→「構成マネージャ」でもひらける。
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
＞通常遅くは無い。
これが間違い
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が回収してくれると主張する人がいる