- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
{{category C#}}
!! よいと思うところ
* FCLが意外と使いやすい。Javaのクラスライブラリに比べると、はるかにネーミングやカテゴリ別けが分かりやすい。適当にドキュメントを眺めているだけで、おやっと思って使ってみる、といったクラスがしばしばある。
* forのカウンタ変数やforeachの要素変数がローカルにできる。
* Generic。使いまくり。
* リテラル文字列がある。これがなくてやってられるか。
!! 微妙なところ
* デリゲート。分かりにくくはないと思うが。
* SDKに最新のコンパイラをつけて欲しい。まあ、現実に.NET 3.5のプラットホームってほとんどないから、まだC# 2.0でもいいけど。
* 何かと言うとVisual Studioが出てくる。RADツール使うと、余計な決まりごとを覚えなくてはならないし、そんなに生産性上がるか？特にGUIなぞまったく作る気がないユーザは。それに、フレームワークも見えにくくなって理解が進まない。とにかくGUIなんぞ余計なものは絶対に作りたくない。 => 最近はオライリーの本が増えてよい。VSなんて使いたくないし覚えたくない。
* 意外と速いけど微妙な遅さ。
閑話休題：
今まで漠然と、CLRはJVMみたようなもの、と思っていたが、よくよく読んでみると違うらしい。
MSILはCLRによって逐次実行されることは決して無い。
MSILは必ずJITコンパイルされ、コンパイルされたネイティブコードが実行される（それを管理するのがCLR）。
ということは、実行時に、ILを実行しなければならないコストはゼロのはずだ。なぜならILはそのままでは決して実行されないから。実行開始時にコンパイルされるだけ。
で、ネイティブコードが実行されるなら、なぜ.NETアセンブリの実行はこんなにも遅いのか。
* CLRによる実行管理のオーバーヘッド。ガーベッジコレクションとかアプリケーションドメインの管理やリフレクション情報の管理など、普通のC/C++アプリケーションが行っていないことを行わなければならない。
* FCLの実行が遅い。
といったことが考えられる。
MD5計算ではPerlにもひけを取らないのに、テキスト処理になるととたんに遅くなったりするのは後者の関係なんだろうな。。。
現在では、JREとはJVM + JITコンパイラのことのようなので、CLRとほぼ同じようなものであろう。Javaバイトコードが逐次実行されることは現代ではもはやない、ということなんじゃないだろうか。