.NETでCILとCLRが必要なのはなぜですか？

ここでこの素敵な画像を見ました。.net言語をサポートするすべてのコンパイラがソースコードをCILフォーマットに変換することを学びました。現在、Microsoftは.NET、すべてのオペレーティングシステム用のCLRを作成して、すべてのオペレーティングシステムを導入することはありません。次に、そのような中間コード形式とそのCILを実行するためのCLRを保持する理由。それは対処する頭痛ではありません。なぜマイクロソフトはこのように選んだのですか？

編集このちょっとしたアーキテクチャには価格があります。パフォーマンスが低下しますか？Javaはプラットフォームの独立性を維持するためにこれを行いますが、どのような理由で.NETがそれを行いますか？コンパイラのような単純なプレーンなCを保持しないのはなぜですか。また、新しい言語を追加する必要がある場合、どのような方法でもコンパイラーがコードをCILに変換する必要がありますが、唯一の違いはターゲット言語です。Tat's all。

なぜなら、C＃のCILにコンパイラを1つだけ書く必要があるからです。プラットフォームごとにCILのインタープリター（または多くの場合、ジャストインタイムコンパイラー）を作成することは、C＃から（プラットフォームごとに）実行可能コードにコンパイラーを作成するのに比べて比較的簡単です。

さらに、ランタイムはCILにコンパイルされるものなら何でも処理できます。新しい言語（F＃など）が必要な場合は、1つだけ記述する必要があります用のコンパイラをで、.NETがサポートするすべてのプラットフォームサポートを自動的に取得できます。

ああ、私は.NET dllを取得し、それをWindowsまたはLinuxでMono経由で再コンパイルせずに実行できます（すべての依存関係が満たされていることを前提としています）。

パフォーマンスに関しては、議論の余地があります。基本的にCILを取得してネイティブバイナリを作成する「プリコンパイラ」があります。ジャストインタイムコンパイラーは、静的コンパイラーでは不可能な最適化を行えると主張する人もいます。私の経験では、アプリケーションが何をしていて、それを実行しているプラ​​ットフォーム（そのプラットフォームでのJITerの大部分）に大きく依存します。.NETで十分ではないシナリオに遭遇することは、私にとって非常にまれです。

.NETには、Javaと同じ理由で、中間言語（CIL / MSIL）とプラットフォーム非依存ランタイム（CLR）のプラットフォーム固有の実装があります。Microsoftは、C＃がJavaと直接競合することを意図していましたが、Microsoftがターゲットとする（自社の）OS上でJavaと競合します。

.NETはWindowsプラットフォーム（またはMono / Linuxのような.NETに類似した他のOS）でのみサポートされていますが、Javaに似ています：

• マネージメモリランタイム-アンマネージC / C ++とは異なり、C＃/ VB.NET開発者はオブジェクトの有効期間を厳密に制御することを心配する必要はありません。Javaと同様に、CLRには、スコープ内のヒープ内のオブジェクトを自動的に解放するガベージコレクターがあります。これは、アンマネージランタイムに慣れている人にはささいなことかもしれませんが、C / C ++で非常に一般的なポインター演算の「ブラックマジック」を思いとどまらせるという極端な二次的な利点があります。
• プラットフォームの独立性-Windows VistaおよびWindows 7は、Windows XPとは異なる動作をします。Windows 8の動作は異なります。Windows 8 Mobileを含むWindows Mobileバージョンの動作は再び異なります。異なるハードウェア、異なるアーキテクチャ、異なる機能。.NET開発者にとってターゲット環境は依然として重要ですが、専門知識の量は、これらのすべてのOSに対して互換性のあるC / C ++プログラムを構築するために知られているものに比べてはるかに少なくなります。AC＃devは、さらに無料で入手できます。
• Webアプリケーションのサポート-C ++でゼロから作成された、クライアント向けのサーバースクリプトWebアプリケーションはまだ見ていません。Web サーバー、確かに、Apache、ISS、それらはすべて、速度/効率の理由から、通常、すべて管理されていないランタイムに対して実行されます。ただし、C ++はWebアプリケーションの構築に使用される言語ではありません。C＃は（Javaと同様）です。Microsoftの次世代ASPパラダイムをサポートするためにゼロから設計されました。これは、サンドボックスで実行するように設計されたコードです。どのサンドボックス（ISSへのASP.NETプラグインまたは "デスクトップ" CLR）は比較的重要ではありません。
• 言語/ランタイムの独立性-C ++コンパイラは、C ++ソースコードを受け取り、1つの機械語を使用して1つのプロセッサアーキテクチャのアセンブリコードを生成します。異なるアーキテクチャやマシン言語をサポートするには、まったく新しいコンパイラーを作成する必要があります（そして、まったく新しいランタイムライブラリのセットをコンパイルする必要があります）。AC＃コンパイラはC＃ソースコードを取得し、CILを生成します。CILは、ハードウェア固有のJITerがマシンコードに変換します。同じJITerは、ソース言語（C＃、VB.NET、F＃、およびIronHaskell、IronRuby、IronLispなどの「Iron」言語ポートのホスト）に関係なく、CILプログラムを翻訳できます。同じコンパイラーは、ハードウェアに関係なく、JITerが実行できる1つの言語をCILに変換できます。
• 「正しい」コードに焦点を当てる-C ++開発者にとって、最も重要なことに応じて、何かを行うための「正しい」方法がたくさんあります。メモリの効率、CPUの効率、ハードウェアの独立性、OSの独立性などです。これらのそれぞれが優先順位である場合、コードは大きく異なるように見えます。C＃は、ファウラーと彼の同僚（C ++から大幅に移行したコミュニティにオブジェクト指向の原則を教えることでC ++コミュニティ内でコード設計を改革するために働いていた）の概念的教訓を心に留めたグループによって設計されました。以前に来た言語で学んだ実践的な教訓（Java、およびオールマイティなオブジェクトへのほぼ完全な従順を含む、古き良きC ++スタイルの関数ポインターがはるかにきれいに仕事をし、より少ないオブジェクトではない場合-指向）。

独占禁止法の理由から、MSはAndroid、Mac OSX / iOS、Linuxなどの他の主要なプラットフォームで「干渉」しすぎないように注意しています。ただし、実際にはこれらの3つのプラットフォームすべてで開発中のチームがあります。OSにはMSが開発したバージョンのOfficeがあり、iOSおよびAndroid用のOffice相互運用アプリを含む多数のアプリケーションがあり、Skype（現在はMicrosoft製品）がLinux上で実行され、MicrosoftはLinuxカーネル（主に仮想化の考え方）。

Windows OSはさまざまなCPUタイプで利用できますが、現在は主にx64、x86、Intel、ARMです。

CIL / CLRは、そのハードウェアプラットフォームから独立しています。これらの違いは、IL実行環境によって「抽象化」されます。たとえば、「任意のCPU」用にコンパイルされた.NETアセンブリは、通常、64ビットプロセスとしてWin64上で、32ビットプロセスとしてWin32上で実行でき、異なる実行可能ファイルを提供する必要はありません。

さらに、CILを使用すると、ネイティブDLLでは簡単に実行できないアセンブリにメタデータを保存できます（もちろん、MSは以前にCOMコンポーネントでこれを行っていましたが、そのテクノロジは.NETコンポーネントほど簡単に処理できませんでした）。これにより、ソフトウェアコンポーネントの作成が非常に簡単になり、すべての.NET言語でのリフレクション/イントロスペクションの基盤となります。