- 1 名前：デフォルトの名無しさん [2005/09/11(日) 23:54:01 ]
- おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！
- 347 名前：310 mailto:sage [2005/12/10(土) 11:52:44 ]
- >>345
ループ1回で+3sかかりますか？
- 348 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 12:39:12 ]
- >347
それはなかった。何らかのコストがかかっているのは確かみたい
CLR 側のやつはDateTime とか Console::WriteLine を使っていたので、ソースを完全に
同一にすると、
lstrcmp 19s 17s
になった。1億回のループでこれだから、あとはパフォーマンス・カウンタでも使わないと
細かくはわからない領域だと思う
ちなみにいろいろと切って静かに取ってみたら
CLR Native CLRx64 Nativex64
lstrcmp 16s 14s 15s 12s
なんて結果になった
- 349 名前：310 mailto:sage [2005/12/10(土) 12:52:57 ]
- >>348
342のソースはSTLの負荷が大きいのと、strcmpはインライン化されて
マネージ、ネイティブの切り替えは見えにくくなってると思う。
だから純粋にネイティブとCLIの差じゃなかろうか。
STLとっぱらってstricmpとかだけにしたらこちらの結果と
相似に近いのが出るんじゃないかな。
STLはマネージ側で実行されるんでしょ？ だからネイティブとの
大きな差にはならないんじゃないのかと。←こっちより差が小さいから
- 350 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 12:59:11 ]
- >349
んにゃ。STLはネイティブだよ。ループで代入しているのは、最適化でループ自体が外される
のを防ぐため
しかし、CLRx64 にはもうちょっとがんがってほすぃ
- 351 名前：310 mailto:sage [2005/12/10(土) 13:01:25 ]
- >>350
>STLはネイティブだよ
ありゃそうなの？ テンプレートっつーくらいだから
マネージとしてコンパイルされてるのかと思った。
- 352 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 13:05:46 ]
- >351
それはジェネリクスを利用した STL.NET と混同してるんじゃないかな
しかし、+2秒はいったい何をしているのだろう
- 353 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 13:18:58 ]
- 気になったので試してみた
List<int>^ results = gcnew List<int>;
time_t stm = 0;
time(&stm);
for ( unsigned long int i=0; i<100000000; i++ )
{
results->Add(lstrcmp(a, b));
}
time_t etm = 0;
time(&etm);
std::cout << "Result : " << etm - stm << " Size : " << results->Count << std::endl;
CLR Native CLRx64 Nativex64
lstrcmp 13s 11s 12s 9s
なかなか、よい結果です
- 354 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 22:23:25 ]
- >>346
数学苦手だった人?
- 355 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 22:28:52 ]
- 直線と言っても限りなく水平に近いものから限りなく垂直に近いものまであるわけで。
- 356 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 00:48:46 ]
- >>353
ｽｹﾞｰな
- 357 名前：デフォルトの名無しさん [2005/12/11(日) 03:32:29 ]
- .net2.0SDKにはC++/CLIのコンパイラって付いてくるの？
managedC++は？
- 358 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 04:57:42 ]
- ついてこない。
- 359 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 05:03:06 ]
- えええええええええええええ
- 360 名前：デフォルトの名無しさん [2005/12/11(日) 07:55:17 ]
- .NET 1.0のmanaged c++の頃にやったテストなのだが、
C#やVB.NETでも使えるP/Invokeに比べて、
importlibで呼び出す場合はかなりパフォーマンスがよかった。
単純なNativeコードのDLLを作り繰り返し交互に呼び出すテストで、
かかった時間はP/Invoke 24, importlib 3
nativeコードからimportlibを使っての呼び出し 1.5 の比率。
DLLを作らずobjのリンクの場合、native-nativeで１、managed-nativeで2.5。
というわけでC++/CLIの存在意義はmix modeにあると思っている。
- 361 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 07:58:58 ]
- >357
cl /clr
cl /clr:oldSyntax
ってやってみな
- 362 名前：デフォルトの名無しさん [2005/12/11(日) 08:05:27 ]
- >>360
つか、今時Win32 APIをコールする必要があるか？？？
- 363 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 08:56:21 ]
- ある
- 364 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 10:14:33 ]
- >>362
まだ大いにあるよ。
- 365 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 10:49:56 ]
- >>362
君にはない。
- 366 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 11:11:19 ]
- >>362
今時っていうか、今程度の.netじゃ、
まともなWindowsプログラミングやるならWinAPI叩かざるを得ない。
- 367 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 12:15:19 ]
- 激同
- 368 名前：デフォルトの名無しさん [2005/12/11(日) 19:40:02 ]
- >>366
そうか〜？
.NET Frameworkのクラスライブラリだけですべて作れますけど・・・
- 369 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:06:45 ]
- いまんところ直面した問題
・ＩＭＥ
・Ｃａｒｅｔ
・ScrollWindowEx
- 370 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:08:00 ]
- >>369
初心者スレ行けばｗ
- 371 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:15:13 ]
- >>370
あほか。流れ嫁。API呼ばなきゃいけない問題だ。かす。
- 372 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:22:17 ]
- >>371
初心者スレ行けばｗ
- 373 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:29:00 ]
- >>368
SHFileOperation
VBのMyを使えとか言ったら刺す。
- 374 名前：流れを読んでレス mailto:sage [2005/12/11(日) 22:03:40 ]
- >>371
初心者スレ行けばｗ
- 375 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 22:21:02 ]
- >>368
FileDialogのカスタマイズ
- 376 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 00:10:36 ]
- >>375
初心者スレ行けばｗ
- 377 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 01:51:23 ]
- こう見るとできないことだらけだね。
MSはどうするつもりなんだろう
- 378 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 09:21:36 ]
- そのためのC++/CLIじゃないか
- 379 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 23:05:18 ]
- >>368
ありふれた業務アプリ程度ならそれほど困ることもないけど、
ちょっとばかしシステムに寄った途端にできないことが増える。
原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
余計に萎えるというおまけが付くこともよくある。
>>377
とりあえず使い物になるVer.3を出せと言いたい。
- 380 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 09:00:43 ]
- >原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
>余計に萎えるというおまけが付くこともよくある。
あるあるｗｗ
- 381 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 15:22:20 ]
- ttp://s03.2log.net/home/nsharp/archives/blog404.html
正直賛同できません。
- 382 名前：デフォルトの名無しさん [2005/12/13(火) 17:15:19 ]
- Cに勝る言語はないってことだな
- 383 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 20:46:50 ]
- Win32への依存度を下げる必然性がないんだから当たり前でしょ？
- 384 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 21:47:52 ]
- Win95が出たときの3.1使いもそう言ってた
- 385 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:36:34 ]
- Win16→Win32s→Win32のこと?
あれは言語一緒だしね…
- 386 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 05:37:15 ]
- 技術的な需要もないことはないけど、それよりただ新しいWindowsを
作らないといけないことだけが先行してるのが萎える。市場に対して
新規性を謳うことだけが最重要課題なんだよな。
- 387 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 20:41:33 ]
- 次は ISO だな
www.ecma-international.org/publications/standards/Ecma-372.htm
- 388 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 00:54:50 ]
- ISOは無理。
- 389 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 00:59:57 ]
- C#はISOだぞ
C++/CLIだってきっと
- 390 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 08:57:14 ]
- CLI は ISO で標準化されてたっけ？
- 391 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 10:32:21 ]
- CLI 標準はこれだな
ISO/IEC 23271:2003
- 392 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 10:56:26 ]
- このへんね。
www.plumhall.com/ecma/
msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx
- 393 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 23:38:22 ]
- itpro.nikkeibp.co.jp/article/COLUMN/20051125/225170/?ST=win
に「VC++ExpressEditionは標準C++を学習するための優れた教材である 」
てあるけど、そうなの？
.NETのWindowsアプリ作るものかとおもってたよ。
- 394 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:04:06 ]
- とりあえずVC++は標準C++への準拠度が高いことに間違いない。
- 395 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:58:19 ]
- これまでは準拠してなかったということ？
- 396 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 09:38:58 ]
- そゆこと
それからC++でﾄﾞﾄﾈﾄすると飛んでも文法だし、
大体MFCはキショイというのが定説。
- 397 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 13:40:38 ]
- へぇ。２００５からはキショクはないのか。
VC++（というIDE）を使ってなかった人も使い出したりするんだろか？
- 398 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:36:35 ]
- IDEがVC6位軽ければみんな使うだろうに
- 399 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 22:31:59 ]
- 自分の価値観を回りに押し付けないように
- 400 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 23:47:53 ]
- ただそこに意見が存在するだけで
押し付けられたとか思い込まないように
- 401 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 14:50:12 ]
- ttp://mag.autumn.org/Content.modf?id=20050425162104
C++復権すると思う？
- 402 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 15:45:19 ]
- >現状で極めて私的な感想から言えば、>JavaとC#の
>代替プログラム言語になり得る第1候補はVisual Basicです。
- 403 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:16:06 ]
- >>401
復権もなにも
C++で記述できないプログラムはないんだから・・・
- 404 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:22:13 ]
- >>403
それは今のCPUがC言語を動かすことを前提としてる面も大きいと思う
- 405 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:28:41 ]
- CPUがC言語を動かす？
意味不明
- 406 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:32:45 ]
- 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん。
他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
- 407 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 21:27:10 ]
- >>406
> 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん
これはOSの問題という側面のほうが大きいと思う。
別にC/C++ではヌルポインタのビットパターンは0でなくとも良いとなっている。
> 他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
そんなもん誰も要求していない。
- 408 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 07:22:14 ]
- >>406
x86のI/Oポートは「C言語」では叩けないよ。
喪前様が言ってるのは、例えるなら、見かけの現象だけで
「太陽は地球を回っている」と言ってるのと同じこと。
言語側から見るだけじゃ、本当の意味では計算機は理解できない。
計算機の基礎から勉強したほうがいい。
- 409 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 08:14:09 ]
- x86のI/Oポートをたたく必要がない
- 410 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 10:44:15 ]
- >>403
「brainfuck復権すると思う？」
「復権も何も、brainfuckで記述できないプログラムはないんだから……」
- 411 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 10:48:17 ]
- >>410
いまだにつかっていますが、なにか？
- 412 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 07:42:22 ]
- みんなの大好きなあの言語が.NETの仲間入り。
brainf*ck.NET
- 413 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 11:36:51 ]
- >412
ソースコードｷﾎﾞﾝ
- 414 名前：デフォルトの名無しさん mailto:sage [2005/12/27(火) 21:13:53 ]
- C++/CLIの入門サイトってありますか
- 415 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 10:29:47 ]
- VB.NET のPGで、構文解析を行う必要が出たときに、
C++/CLI で boost.spirit 使って手軽に構文解析モジュール作成して、
VB.NET から参照設定で呼び出す
ってことが簡単に出来るならすばらしいことだと思うよ。
- 416 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 10:32:23 ]
- マルチランゲージは素晴らしい。
現実はJ#は開封もされない事実。
ﾌﾞﾋﾞ厨はＣ貧を嫌い、Ｃ貧はﾌﾞﾋﾞ厨を嫌う。
Ｍ＄の理想は宣伝専用。
- 417 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 00:42:11 ]
- >415
普通にできるけど？
- 418 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 05:23:34 ]
- C#で以下のようなコードを
using (FileStream fs = new FileStream("test.txt", FileMode.Read)) {
}
C++/CLIでうまくかけるんですか？
FileStreamをスタックみたいにして作れると思ったんですが、できないのでしょうか？
- 419 名前：418 mailto:sage [2005/12/29(木) 05:25:15 ]
- すいません。できました。ぜんぜんわかってませんでした。
- 420 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 17:16:57 ]
- >414
入門するようなもんじゃねぇだろ？
C# を先に勉強した方がいいぞ
- 421 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 20:22:02 ]
- このスレでC#を勧めるのはどうかと思う。
- 422 名前：デフォルトの名無しさん mailto:sage [2005/12/30(金) 00:13:58 ]
- そうか？ 基本的にC++/CLIのターゲットは、今までC++をやってきた連中が .net
Framework を自由に使えるようにと言うことだろ
表面的な文法なら、ref や generics にプロパティ、delegate ぐらいしか増えないわけで
今までC++をやっていたのであれば、それほど大した変更じゃない
問題なのは、.net Framework を使えるか、それをC++/CLIではどのように融合させたのか
という点だから、それは入門じゃないだろ。C# の入門書見て、C++/CLI の構文での使い方を
知れば、十分なんじゃねえかと思われ
ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
- 423 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 08:04:27 ]
- >>422の言ってることは確かに理解できるし、俺もほとんど同意だが。
ここはC++/CLIについて語るスレなんだよなｗ
でもマジレスすると、入門サイトありますか？とか聞くようなレベルなら
さっさとC#かVBで始めたほうがいいと思う。
- 424 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 13:05:55 ]
- _asm{} とか書いたらどうなるんだ？って思ってやってみたら、
さすがに main() の中に書いたら怒られた。
関数単位でマネージド、アンマネージドが切り替わるんだね。
_asm{} 入りの関数はネイティブコードとして生成されるみたい。
その呼び出しをうまい具合にやってくれるのがいいね。
いや、C++/CLI で _asm{} 使うような機会があるかどうかは別として。
- 425 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 14:20:04 ]
- >424
C++/CLI の拡張構文ではグローバルな関数の存在を認めていない
だから、ただ関数を生成しただけでは、基本的にネイティブとしてコンパイルされる
はずだよ。main はさすがに扱いが違うけど
- 426 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 15:09:22 ]
- ふと思ったんだが boost on C++/CLI なんて可能だろうか。
ていうか、だったら素直に .NET Framework にある
便利クラス使えよって気もするが。
- 427 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 16:19:01 ]
- アセンブリ内で閉じてるなら平気だろ
CLI 拡張部を使わなければ、標準のC++であることが C++/CLI の設計コンセプトなんだから
できない理由はない。聞く前にやれば？
- 428 名前：デフォルトの名無しさん [2006/01/01(日) 00:43:38 ]
- if ( DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;
コンパイルできません＞＜
t:\dev\www\winform\winform\Form1.h(154) : error C2039: 'OK' : 'System::Windows::Forms::Form::DialogResult' のメンバではありません。
t:\dev\www\winform\winform\Form1.h(23) : 'System::Windows::Forms::Form::DialogResult' の宣言を確認してください。
t:\dev\www\winform\winform\Form1.h(154) : error C2065: 'OK' : 定義されていない識別子です。
ビルドログは "file://t:\DEV\WWW\winform\winform\Debug\BuildLog.htm" に保存されました。
winform - エラー 2、警告 0
========== ビルド: 0 正常終了、1 失敗、0 更新、0 スキップ ==========
- 429 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 00:46:55 ]
- if ( Windows::Forms::DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;
こうしました＞＜
- 430 名前：デフォルトの名無しさん [2006/01/01(日) 01:19:56 ]
- Ｃ＋＋／ＣＬＩやりたいやつが入門サイトを希望するなんて
ギャグ以外の何者でもないだろ。
- 431 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 12:25:43 ]
- CLIマッシーンってどんな環境を目指しているの？
そのうち出るかもしれない3DのUIとか検索ベースのFSまでのつなぎかな？？
- 432 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 13:21:49 ]
- いつかでるLISPマシンまでの繋ぎです
- 433 名前：デフォルトの名無しさん [2006/01/01(日) 15:25:53 ]
- >C++復権すると思う？
それ以前にC++ってメジャーだったっけ？
- 434 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 19:16:48 ]
- >433
どっかの記事では1990年代は優勢とか、書いてあったな。
- 435 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 21:07:00 ]
- C++/CLIのライブラリは .NET のライブラリをそのままISO標準にするの？？
以前のライブラリを使えるのはいいけど、できればGCで楽したいなー。
- 436 名前：デフォルトの名無しさん [2006/01/01(日) 21:58:51 ]
- 1990年代の段階ではC言語の仕事ばっかりやらされていたな。
- 437 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 22:49:23 ]
- >>433
Java/C#なんかが出てくる前は優勢だったと言えるだろう。
ただしベターCとしてしか使われなかった割合も大きかっただろうが。
- 438 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:37:51 ]
- delegateとeventの違いがわかりません。
delegateだけでいいような気がするのですが。。。
eventが存在する理由を教えてほしいです。
- 439 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:40:52 ]
- delegateを簡単に扱うため
- 440 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:46:17 ]
- ＞＞439
センセー！簡単になる場面が思いつきません＞＜
- 441 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:52:42 ]
- event なら delegate の呼び出しが外から出来ないでしょ
- 442 名前：デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:53:11 ]
- >>440
うるせーな。少しは自分で考えろ。
delegateは関数オブジェクトの取り扱いの簡便化ため。
eventはdelegateの呼び出しの簡便化のため
- 443 名前：デフォルトの名無しさん mailto:sage [2006/01/02(月) 14:27:27 ]
- >>438
つか比較すること自体が変だ。
delegateは型、eventはメンバ。class(型)とメンバの違いが分かりませんって
言われたってこっちが説明に困るよ。
- 444 名前：440 mailto:sage [2006/01/02(月) 23:54:45 ]
- >>441
そこらへんが答えだと思うんですが、まだよくわかりません。
>>442
＞eventはdelegateの呼び出しの簡便化のため
は
＞delegateはdelegateの呼び出しの簡便化のため
でもいいとおもうんです。eventなど持ち込まなくてもできると思うんです。
>>443
例えば、
public delegate void LogHandler(string message);
public event LogHandler Log;
を
public delegate void LogHandler(string message);
public LogHandler Log;
と書いても動くと思うんです。
まだ.NET初心者なのではずしてるかもしれませんが。
- 445 名前：440 mailto:sage [2006/01/02(月) 23:56:41 ]
- あ、上のコード例はC#です。
- 446 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 00:10:51 ]
- event がないと AddListner やら RemoveListner を自前で実装せにゃならんのさ
- 447 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 00:38:44 ]
- >>444
あー、イベントというものが根本的に分かってないんだろう。
メンバで表現されるものを他の言語と比較すりゃわかると思う。
CLRでのクラスメンバにもてるものはフィールド、メソッド、「プロパティ」、「イベント」なのよ。
後者二つがあることがいわゆるC#が「コンポーネント指向言語」っていわれる理由でも
あり、ただのdelegateフィールドとは「まったく」別のもの。
こうやって特殊化したことによってTypeDescriptorやらで動的にコンポーネント情報を取得できる。
ちなみに 446 も言ってるが、イベントはフィールドとアクセサ(とメタデータ)でなるんだな。
public event EventHandler TextChanged;
と書いたときに生成されるのは
・privateなdelegateフィールド
・publicなadd, removeアクセサメソッド。
・イベントメタデータ
を生成している。
|
 |
