- 1 名前：デフォルトの名無しさん [2009/02/04(水) 23:26:55 ]
- (#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。
前スレ
C#, C♯, C#相談室 Part50
pc11.2ch.net/test/read.cgi/tech/1229661915/l50
Visual C# 2008 Express Edition 日本語版
www.microsoft.com/japan/msdn/vstudio/express/vcsharp/
その他テンプレ>>2-5くらい
- 75 名前：デフォルトの名無しさん [2009/02/11(水) 19:47:04 ]
- 「CLR via C#」 （邦題：プログラミング .NET Framework） は、C#使いならEffective C++並に必読といっていいぞ。
邦題のタイトルのせいでスルーされがちだけど。
- 76 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 19:58:46 ]
- >>75
www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0Microsoft-NET-Framework-%E7%AC%AC2%E7%89%88-%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%BD%E3%83%95%E3%83%88%E5%85%AC%E5%BC%8F%E8%A7%A3%E8%AA%AC%E6%9B%B8/dp/4891005238/
ref=sr_1_1?ie=UTF8&s=books&qid=1234349867&sr=1-1
これ？
- 77 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:02:54 ]
- >>76
www.amazon.com/CLR-via-Second-Pro-Developer/dp/0735621632
これに対応する物だろうけど、MS日本法人はもうちょっと考えたほうが
いいよな。Amazon自体のデザインは日米共通だが、笑っちゃうくらい
印象が違う。
- 78 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:05:51 ]
- >>77
どれ？ｗ
- 79 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:07:44 ]
- >>76
それ
Amazonのリンク張る時は、この短いやつで十分
www.amazon.co.jp/dp/4891005238/
>>75
C#使いなら手元に置いて、しっかり読んでおきたい本だね。
- 80 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:13:21 ]
- >>75
第2版なら持ってる。
そんなにバリバリプログラミングするぞって本とは思えないな。
要らない事書いて恥じ書く前の、転ばぬ先の杖ってヤツ？
…改めて見てみると、かなり付箋や自分のメモ書きが入ってたんだがw
- 81 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:17:39 ]
- >>79
GJ
ん〜買おうかな
迷うぜ
- 82 名前：デフォルトの名無しさん [2009/02/11(水) 20:20:11 ]
- Amazonのカスタマーレビューの投稿数からして、日本と米国じゃ圧倒的な差だな
日本は所詮プログラミング後進国ということか・・・
- 83 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:30:55 ]
- まー 古い本だから安く手に入ったり、譲って貰えたりするんでないかな？
古いからジェネリックとか無いけど、
多分ジェネリックを含む新しい本が今後出ても、
その本にはこれと同じ内容の章を割くことになる。
(逆にその本がILコードの都合にまで言及してくれるかは解らん)
- 84 名前：デフォルトの名無しさん [2009/02/11(水) 20:32:47 ]
- ジェネリックは載ってるよ。
- 85 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:36:48 ]
- ごめん。
古いから載ってなかった物がなんかあったような気がするが、覚えとらん。
言い訳にならんが、一昨年の2月に読んでたんで。
- 86 名前：デフォルトの名無しさん [2009/02/11(水) 20:45:27 ]
- >>85
うん。原書の第２版は2006年に出たらしいから、.
NET Framework 2.0 までの記述になっているので、それ以降のことは載ってない。
でもジェネリックは2.0では既に導入されているから載ってるよ。
はやく３版出ないかな
- 87 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 20:57:19 ]
- Essential.NETのことも忘れないで下さい(´・ω・｀)
- 88 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 22:52:36 ]
- >>87
それ日本語版ある？
CLR via C#は買いたいな
- 89 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 22:58:14 ]
- というか、C#や.netは今後も残るのかな
.netそのものがどうなるか不安だし、言語としてもVBやC++/CLIと比較したらC#はマイナーだし、
なんか漠然とした不安を感じてしまう
だから、いつまでもC#の高い本が買えない 悪い循環になってるorz
- 90 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:02:22 ]
- C++/CLIと比較ww
- 91 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:05:48 ]
- C#>>>VB>>>>>>>越えられない壁>>>>>>C++/CLI
って感じだな。俺の周りでいうと。
- 92 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:06:30 ]
- 米のamazon.comだと日本で高い洋書も結構安かったりするんだけど（特に中古）、
自分の住所の英語表記に自信がない(w)のと、送料が不明確なんでずっと買うの
躊躇してるんだよなあ。
実際米のamazon.comで買ってる人いたら送料どのぐらいか教えてくれない？
- 93 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:11:48 ]
- 言語としてC++は残ってるからなCLIはその拡張版なだけだし
ユーザ数はVB>C++>C#だし、消えるとしたらC#が真っ先に消えるんじゃないか？
- 94 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:12:58 ]
- >>89
というか何年前から来た人ですか
- 95 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:15:16 ]
- 確かにどの現場にいってもC#で開発してるところは少ない
無くならないかもしれないが死に体であることには変わりがないな
少なくとも俺の周りでは
- 96 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:15:34 ]
- >>93
そう思うなら、VBでもC++/CLIでも使えばいいじゃん。
- 97 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:17:50 ]
- すくなくともC++/CLIだけはありえない
それだけは断言できる
- 98 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:20:58 ]
- >>97
なんで？
- 99 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:23:00 ]
- 俺もないと思う。.NET のメリットである、「お気楽コーディング」ができないし。
情報も少ないしね。
- 100 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:25:10 ]
- C++/CLIはなくなっても、C++は残るからなぁ
- 101 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:27:30 ]
- C++ じゃないとダメな分野は依然としてあるからね。
- 102 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:32:04 ]
- C++にはC++にしかできないことをやらせるというのがMSの方針
だから間違ってもC++/CLIは主役にならない
- 103 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:34:51 ]
- となると、かつてVB6でクライアントを開発してたようなシステムは、
まさかVB6ってわけでもないだろうから、.netでVBで開発してるのかな？
- 104 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:35:12 ]
- VC++のカバーして他分野はあんまり侵食してない。
VC++と旧VBの間をカバーしてたDelphiやC++Builderといったあたりが弾き出された感じだな。
- 105 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:37:16 ]
- 2chでそんな公然の秘密みたいな話されてもな。
一人で仕事して、言語の移り変わりを心配してる人がそんなに沢山いるのかな？
極個人的に、数年前に関数型言語への乗り換えに失敗したので、
Boostのlambda系をやろうと思ったら、
C#ってやつで似たような事をやってた。 現在に至る。
一万円で1日遊べればいいので、本代はペイできたと思う。
- 106 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:37:50 ]
- 主役はBasicだから主役には成らないが脇役から外れることもないんじゃない？
ならC++を学んでC++でFrameworkを使うという選択肢は重要な選択肢
- 107 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:39:49 ]
- 主役は Basic って何の話？
VB6 まで、MS のファーストランゲージは VB だったけど、今は C# に変わったよ。
- 108 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:42:12 ]
- >>106
だから奴らは、継承を見ると避難して、switchを沢山使うんだな!
- 109 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:43:50 ]
- >>107
今もVBがメインストリームで、C#はマイナーだろ
- 110 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:46:13 ]
- こういっちゃなんだが C#er は C++ からの人も多い
まぁそういう人らすら大抵既存資産流用とか以外で C++/CLI を
使いたがらないわけで押して知るべしっていうか
- 111 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:47:52 ]
- まともなプログラマなら両方使える。たいした差はないだろうに。
使いこなすのに１０の労力が必要だとして、
クラスライブラリの理解５、IDEの操作３、言語２くらいだからね。
どうでもいいよ。
- 112 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:51:02 ]
- C++/CLIはともかく，C#できるのにVBできないのはもったいない
1時間触れば使えるぞ
- 113 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:52:44 ]
- F#やbooもよろしく
- 114 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:03:57 ]
- 今のVBって今のC#のサブセットにしか見えないんだが、何か違うところある？
構文とキーワード以外で。Variant型ってまだあるんだっけ？
- 115 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:05:17 ]
- わりとC++/CLIに戻る価値があるって言ってる人もおおいじゃん
アレはガゼってこと？
C++: .NET Framework プログラミング最良の言語
msdn.microsoft.com/ja-jp/library/ms379617.aspx
いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
www.atmarkit.co.jp/fdotnet/special/cppcli/cppcli_01.html
C++/CLIはC#を凌駕するかも知れない…… usingステートメント不要のDisposeメソッド呼び出しの衝撃
mag.autumn.org/Content.modf?id=20050506023118
本当は凄いC++!? プログラム比較論 C++ vs C#, Java, Visual Basic
mag.autumn.org/Content.modf?id=20050504145851
- 116 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:08:42 ]
- >>115
無知なので申し訳ないが、簡単な質問なので教えてくれ。
テンプレート有りのライブラリを使った後に、idasm使った事ある？
それとも、あの汚いコードはJITが消化してくれるのか？
- 117 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:08:47 ]
- >>115
多くの記事がVS2005つまり.NET2.0リリース直後じゃないかな。
新製品のことは悪くは書かない。つまりそういうこと。
- 118 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:12:19 ]
- それ川ま(ry。
いやあの人の記事嫌いじゃないというかむしろ好きだけどw
- 119 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:12:22 ]
- >>116
それManaged拡張C++じゃね？
- 120 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:12:47 ]
- >>114
VariantはObject型として実装されてる
メンバ呼び出しは全部リフレクションを使った遅延バインディング
>>115
出たばかりのころは騒がれてたね
C++/CLIとC#を両方ともちゃんと使った上でC++/CLIマンセーしてる奴なんて今時いないよ
- 121 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:13:45 ]
- >>114
書き方以上の違いがあるのはインターフェイスの扱いと、
あとOption Strict Offができるぐらいかね。
たしかにC#でしかできないことの方が逆よりずっと多いから、その意味では
サブセット的存在かもしれん。
- 122 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:14:15 ]
- >>114
クエリ式がC#より充実しているとか、VB6時代の暗黙のインスタンス化復活とかかな。
名前付き引数・デフォルト引数はC# 4.0で入るんだよね。
- 123 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:15:27 ]
- んで、結局、今の開発案件はVBとC#のどっちが多いのかな
- 124 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:15:58 ]
- >>115
Managed C++ → C++/CLI は大進化と言える。
Managed C++ はカオスだったなぁ･･。
- 125 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:17:54 ]
- CreateObject とかは楽だね。
- 126 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:19:04 ]
- サブセットというより機能制限により簡易化と捉えるべきだろ
それこそ、昨日のintとuintの会話と同じ
- 127 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:26:03 ]
- どっちが複雑かということならレガシー機能やダメな子のための機能が満載のVBが圧勝だろ
次のバージョンでC#でもVariantみたいなことができるようになるけど，
必要だから使うのと，わかってないのをごまかすために使うのは違う
- 128 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:29:26 ]
- 結局、VBユーザが流れ込んでC#の良いところがなくなっていくわけね
言語仕様そのものもVBユーザごのみに変わっていきそうだな
- 129 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:33:06 ]
- ぜんぜんわかってないやつがいます。
- 130 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:35:30 ]
- あれは要するに DLR 対応なんだけど。
C# 4.0 に関して、どうして必要か、どういう風に導入するかとい
われたら、ヘジのプレゼン見れば納得すると思うんだけど、
なんか伝聞でへんな風に伝わっていっている気がする・・・
- 131 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:38:34 ]
- また、そうやって荒れる原因になることをいう
C#がVB化するという意味じゃなくて、造詣に深くなくても使えてしまうから、
結果的にVB化するということだよ
VBみたいな言語の仕様での曖昧化を許すということでなく、
結果的に機能について曖昧なままユーザが使用し続けるということさ。
でも本質的には言語のVB化には変わりがないと思うよ
- 132 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:39:31 ]
- Variantとして使えるのも事実だけどな
COM Interopの強化も合わせて，C#4.0になれば
今までVBのほうがやりやすいと言われていたようなことが無くなって
完全にVBと縁を切れるよ
- 133 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:45:10 ]
- >>132
そうなんだ。
ついでにVBのWithEventsとメソッド内のフィールド(Staticで宣言された
ローカル変数)も欲しい。
- 134 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 00:54:24 ]
- Variantとして使う奴が同じグループにいたら全部書き直させるわ
- 135 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 13:59:21 ]
- JavaからC#に移行してきました。
Javaの場合はget/setメソッドでメンバー変数の公開をしていましたが、
C#ではプロパティー機能が存在していますのでこちらを使用しております。
プロパティーを使用していますが使い方としてはget/setメソッドと同様の
使い方しかしてないので、なぜこの仕様が実装されたのか理解できていません。
もしよろしければ理由などについて解説していただけませんでしょうか。
面倒でしたら参考URLをいただければそちらで勉強したいと思います。
- 136 名前：デフォルトの名無しさん [2009/02/12(木) 14:06:20 ]
- >>135
参考URL
blog.inomata.lolipop.jp/?eid=192442
- 137 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 14:46:56 ]
- >>135
www.atmarkit.co.jp/fdotnet/special/java2cs/java2cs_01.html
「あたかも公開しているかのように振舞う使い方」ができるからでは？
- 138 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 15:39:05 ]
- 単にタイプ数が減るからだろ
- 139 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 16:01:24 ]
- >>136
>>137
・呼び出しコーディング非効率の改善
・リフレクションを使うにあたっての非効率の改善
この2点を解消しているってことなのでしょうか？
「あたかも公開しているかのように振舞う使い方」は、
呼び出しコーディング非効率の改善と捕らえてよいのかな・・・。
- 140 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 16:09:17 ]
- リフレクションを使って見るとわかるけれど、プロパティーはフィールド(変数)とも
メソッドとも区別されている。概念として言語レベルでサポートされている。それが
利点の全て。高級言語なのだから。
get_foo, set_fooだと、あるパラメタを取得、設定するメソッドである事をプログラマが
名前で示す単なる慣習に過ぎないけれど、C#ではプロパティという概念によって取得、
設定という行為を特別扱いしている。つまり、get, setメソッドという慣習の事をJAVA言語
は``知らない''けれど、JAVAプログラマは``知って''いた。つまりJAVAプログラマも無意識
にプロパティという概念を持っていたわけ。しかしその概念をJAVAは``知らなかった''。
一方でプロパティという概念をC#は``知っている''。たとえば、あるクラスが持っている
プロパティの一覧を取得するなんて事もリフレクションによって可能。プログラマが扱って
いる概念を言語がサポートしているのは、できる事が増えるわけじゃないけど、高級言語では
素直に喜ぶべき事。それだけ構造性が増すのだから。
まとめると、JAVAでも同じ事を``プログラマが''やっていたんだから、``言語が''同じ事を
やってくれるのを素直に喜べば良い。新しい事ができるわけではないから、使い方はJAVA
と同様で全然良い。ぶっちゃけ、get_foo, set_booとタイプミスしなくて済む機能くらいの
認識でも良い。
- 141 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 16:12:24 ]
- 追記：get, setの中で取得／設定とは言い難い処理まで書けてしまうという問題点はJAVAと同じ。
ただし、C#というか.NETではむしろ逆にプロパティの設定に伴う副作用を積極的に活用する傾向
がある。時々UI関係で面白い事例に出くわす。たとえば、フォームのClientSizeを設定すると
フォームのサイズがClientSizeに合わせて調節されるので、一度、フォームのサイズがおかしく
なるバグを修正するためにthis.ClientSize=this.ClientSizeという字面上は超怪しいコードを書いた
事がある。(とあるツールのアドイン開発で、ロード側の問題なので対症療法するしかなかった)
でも、get, setの副作用は標準ライブラリ以外では濫用すべきではないと思う。そいういう意味
では、JAVAのget_foo, set_fooと本当に同じで良い。自動プロパティなんてのも実装されたし
活用してみたらどうだろう？
- 142 名前：135 mailto:sage [2009/02/12(木) 17:34:12 ]
- >>140-141
判りやすい説明感謝します。
これからは積極的にプロパティーを使って生きたいと思います！
- 143 名前：デフォルトの名無しさん [2009/02/12(木) 19:56:47 ]
- プロパティに関しては否定的な意見もあるけどね。
以下は プログラミング.NET Framework (Jeffrey Richter著, Microsoft Press出版) から
あくまで参考程度に、こういう見解もあるということで。
9.1.1 プロパティを賢く設計する
個人的には、筆者はプロパティが好きではありません。Microsoft.NET Framework
やプログラミング言語でのサポートがなければよかったと思っています。理由は、
プロパティはメソッドであるのにフィールドのように見えるからです。この問題は
大きな混乱を招いてきています。プログラマがフィールドにアクセスしているコードを
見て仮定してしまうことが、プロパティにおいては誤っていることがあります。例えば、
次のようなことです。
・プロパティは読み取り専用または書き込み専用にできますが、
フィールドは常に読み書きできます。プロパティを定義するときはgetとset
のアクセサメソッドを両方提供するのが最善策です。
・プロパティのメソッドは例外をスローすることがあります。
フィールドは例外をスローしません。
・プロパティはメソッドのoutやrefの引数には渡せません。フィールドは渡せます。
・プロパティのメソッドは実行に長い時間がかかることがありますが、フィールドへの
アクセスはいつもすぐに実行が完了します。プロパティを利用する一般的な理由は、
スレッドの同期を取ることです。これはスレッドを永遠に止めてしまうかもしれない
ことを意味します。したがって、スレッドの同期が必要な時にプロパティを使うべきでは
ありません。このような状況ではメソッドを利用するほうが好ましいでしょう。また、
クラスがリモートからアクセスできる（たとえばクラスがSystem.MarshalByRefObjectから
派生している）場合、プロパティメソッドの呼び出しはとても遅くなることがあります。
したがって、プロパティよりメソッドの方が好ましいでしょう。筆者の私見ですが、
MarshalByRefObjectから派生しているクラスではプロパティは使うべきではありません。
（続く）
- 144 名前：デフォルトの名無しさん [2009/02/12(木) 19:57:31 ]
- （続き）
・続けて繰り返し呼び出された場合、プロパティは毎回異なる値を返す可能性がありますが、
フィールドは常に同じ値を返します。System.DateTimeクラスにはNowという読み取り専用の
クラスがあります。このプロパティは現在の日付と時間を返すため、呼び出されるたびに
異なる値を返します。この実装は誤りで、MicrosoftでもNowをプロパティではなくメソッドに
直せるものなら直したいと考えています。
・プロパティメソッドは副作用を持つ場合がありますが、フィールドへのアクセスには
そのようなことはありません。言い換えると、型のユーザーがさまざまなプロパティに
値を任意の順序で設定できて、型の動作に違いがでないようにすべきだということです。
・プロパティメソッドは追加のメモリを必要とするか、オブジェクトの状態の一部では
ない何かへの参照を返して、そのオブジェクトを操作しても元のオブジェクトには
何の影響もない場合があります。フィールドは常にオブジェクトの状態の一部であることが
保証されているオブジェクトへの参照を返します。コピーを返すようなプロパティを利用すると
開発者は混乱します。また、このような仕様がドキュメント化されていないこともあります。
プロパティは使われすぎているというのが筆者の懸念です。プロパティとフィールドの違いを
一覧すれば、プロパティを定義する方が使いやすく、かつ開発者の混乱を招かないパターンは
非常に少ないことに気づくでしょう。プロパティによって得られるのは、少々単純化された構文
だけです。パフォーマンスの向上もない上に、コードは読みづらくなります。もし筆者が、.NET
Frameworkとコンパイラの設計に関わっていたら、プロパティを提供することはなかったでしょう。
代わりに、開発者にGetXxxやSetXxxというメソッドを必要に応じて定義させるようにしていたこと
でしょう。コンパイラが何か特殊な、単純化された構文でこれらのメソッドを呼び出せるように
したいなら、そうすればよかったのです。ですが、フィールドアクセスとは異なる構文を使って
欲しいと思います。開発者が何をしているのか（つまりメソッドを呼び出しているということを）
しっかり認識できる構文ということです。
- 145 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 19:58:19 ]
- public class MyGenericClass<T> where T:（Intとかfloat）{
T example(T a,T b){
return a * b;
}
}
operator*が使える型を取るときwhereにはなんと書けばいいのでしょう？
- 146 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 20:00:13 ]
- >>145
今のところできません
- 147 名前：145 mailto:sage [2009/02/12(木) 20:08:29 ]
- できませんか。コピペでbyte,short,ushot,,,,ulongつくります
- 148 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 20:41:14 ]
- 演算子の実装を表すインタフェースが欲しいってのは常々議論されているけれど、
C#4.0でも解決されないみたいだね。
- 149 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 20:49:24 ]
- ExpressionTree使う
- 150 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:14:47 ]
- >>144
つまりWPFのSetValue(オブジェクト、型.依存プロパティ)はグッドという事か。
これはこれで超冗長だけど、まあロジカルではある。しかも添付プロパティなんて
芸当も可。
- 151 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 21:39:27 ]
- >>148
よく知らずに突っ込むけど、そんな議論あるの？
演算子って普通staticじゃないか
- 152 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:05:41 ]
- インタフェースというより、ジェネリック制約が欲しいという話のことが多い気がする。
いずれにせよ、目的は>>145をどうにかしたいということなんだけど。
- 153 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:12:27 ]
- >>151
いやだから>>145みたいなケースで型制約を
where T: Imultiplicative
とか書ければ万事オッケー、みたいな。別に演算子の実装をインタフェースの実装でやりたい
わけじゃなくて、演算子の実装を表す型制約があって欲しいという事。だから
where T: multiplicative
って書けて欲しい、という話とも言える。
「C# 四則演算 ジェネリック」でググると、MSDNフォーラムとかわんくま同盟の人たち
とかの議論がわんさか出てきます。
>>149はどういう風にやるの？ExprssionTree詳しくないのでちょっとイメージできないんだけど。
- 154 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:34:10 ]
- >>151
ここの過去スレでも出てきてるね
www.23ch.info/test/read.cgi/tech/1194956418/295-312
他にもあったような
- 155 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:38:44 ]
- >>151
ここの過去スレでもやってた
www.23ch.info/test/read.cgi/tech/1194956418/295-312
- 156 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:40:03 ]
- ごめんね
>>154-155は書き込み失敗したかと思った
- 157 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:53:25 ]
- >>153
T example(T a, T b)
{
- 158 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:53:58 ]
- ミスったので帰ります
- 159 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 23:16:17 ]
- >>154
普通に2chのURLはってくれお
pc11.2ch.net/test/read.cgi/tech/1194956418/295-312
- 160 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 23:40:37 ]
- ごめんね
次からそうする
- 161 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:17:39 ]
- >>143
プロパティ否定するのなんて、初期のJava信者だけだろ。
そのJavaにもプロパティ実装されて、否定してた連中涙目。
- 162 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:22:42 ]
- java7のプロパティもクロージャもキャンセルのふいんき（なぜかｒ）らしい。
- 163 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:34:30 ]
- プロパティは属性だから、それを求めるのに特定の機能が使いまわされやすいからな
string mText;
public bool IsEmpty
{ get { return this.GetIsEmpty(this.mText); } }
protected bool GetIsEmpty(string text)
{ return text == ""; }
みたいにGetIsEmptyを基底クラスにまとめて置けば、
継承先ではメンバ変数を渡すプロパティを書けばいいだけで楽。
- 164 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:08:42 ]
- >>153
Expression Tree使うとこういうのが簡単に作れる
static class GenericCalculator<T> {
private static readonly Func<T, T, T> add;
static GenericCalculator() {
var left = Expression.Parameter(typeof(T), "left");
var right = Expression.Parameter(typeof(T), "left");
add = Expression.Lambda<Func<T, T, T>>(Expression.Add(left, right)).Compile();
}
public static T Add(T left, T right) { return add(left, right); }
//他の演算子も同様
}
- 165 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 03:22:34 ]
- 153です。
>>164
add=(Func<T,T,T>)((l,r)=>(l+r));って書くのと同じじゃん、と一瞬思ったけど、
Compile()は当然実行時評価なのかー！。
型制約が欲しい、というのとは話が違くて、足し算ができないと実行時に例外が投げられるのね。
勉強になった。
それなら、CodeDOMでも良いかな？
この手の議論って型制約の話とは別にダックタイピングができればなあ、って話にもなりやすい
けれど、それを無理やりやる方法があるって事だね。
- 166 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 04:34:58 ]
- 書いてみた。ごめん、164を使ってくれ。今は反省している。
class Multiplier<T>
{
public T Mult(T l, T r)
{
string nameOfT = typeof(T).FullName;
string assemblyOfT = typeof(T).Assembly.ManifestModule.FullyQualifiedName;
CompilerResults cr = null;
- 167 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 04:35:44 ]
- 続き
using (CodeDomProvider provider
= new CSharpCodeProvider(new Dictionary<string, string>() { { "CompilerVersion", "v3.5" } })) {
CompilerParameters cp = new CompilerParameters() {
GenerateInMemory = true
};
cp.ReferencedAssemblies.AddRange(new string[] { "System.Core.dll", "mscorlib.dll", assemblyOfT });
string className = "Multiplier_" + nameOfT.Replace('.', '_');
string namespaceName="GenericTest";
string qualifiedClassName = namespaceName + "." + className;
string source = "namespace " +namespaceName+"{ public class " + className + "{public " + nameOfT + " Mult(" + nameOfT + " l, " + nameOfT + @" r){return l*r;}}}";
- 168 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 04:36:29 ]
- さらに続き
cr = provider.CompileAssemblyFromSource(cp, source);
if (cr.Errors.HasErrors) {
throw new Exception(String.Join(Environment.NewLine, cr.Errors.OfType<CompilerError>().Select(e => e.ToString()).ToArray()));
}
Type typeOfMultiplier = cr.CompiledAssembly.GetType(qualifiedClassName);
Object multiplier = Activator.CreateInstance(typeOfMultiplier);
MethodInfo multiplierMethodMult = typeOfMultiplier.GetMethod("Mult");
return (T)multiplierMethodMult.Invoke(multiplier, new object[] { l, r });
}
}
}
- 169 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 06:08:29 ]
- 同じ話題を
d.hatena.ne.jp/NyaRuRu/20060802/p1
で見つけたんだけど、ここに
------------------------------
.NET で動的に実行コードを生成する方法はいくつかあり，またその方法は増えつつあります．
* (.NET 1.0 以降)CodeDOM やコンパイラによる動的コンパイル
* (.NET 2.0 以降)Lightweight Code Generation (LCG)
* (.NET 3.5 以降?)Expression Tree による動的コンパイル
--------------------------------
とあるので、俺のCodeDOMの方法は一応.NET1.0でも使えるという利点はあるみたい。
あと、このサイトではExpression Treeはコードのセマンティクスをデータ構造として保持
するために用いる、という哲学が示されていて、著者的には直ちにExpression Treeをコンパイル
するような使い方はしっくりしないらしい。まあでも>>166-168を書くくらいなら>>164を
書くわな。
このサイトには>>164と同じ方針で作った演算子オーバロード付きの四則演算のジェネリック型
とそれを用いた複素数のジェネリック型のサンプルもある。この手の話って頻繁に繰り返されて
いるように見えるのでまとまった解決法はないと思っていたけれど、これはそのまま直ちに
利用可能だね。
夜中に目が覚めてしまったので色々書いてしまった。連投＆長文すまない。
- 170 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 06:16:59 ]
- 足し算のためにデリゲート呼び出すのもインターフェース越しにアクセスするのも
現実的ではないでしょう
- 171 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 07:58:44 ]
- そういう事書いてる奴誰かと思ったらやはりNyaruruか・・・
- 172 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 08:26:23 ]
- >>170
パフォーマンス的に？
C++のテンプレートみたいな「超高機能なマクロ」にしないと決めてる以上、
それはしょうがない。
>>171
しかも、他のMVPが「いまさら」盛り上がってる中、
NyaRuRu さんだけは「そういえば昔書いたけど」だし。
- 173 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 08:42:40 ]
- >>170
基本的な値型だけを対象にしたければ、素直に大量にオーバーロード書けば良いのでは？
まあその場合も型制約でOR論理を使いたい、ってな議論はできるけれど、興味深くはない。
- 174 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 08:50:03 ]
- >>173 みたいな方法も、
ソース冒頭に
using ValueType = System.Double;
とか書いておいて実装して、
このソースをコピって冒頭の1行書き換えるだけで可能だしね。
美しくはないけども、何とかならないレベルじゃない。
- 175 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 08:50:09 ]
- 別にintと、あとdoubleがあれば十分じゃないかと思うけど
|
 |
