管理言語とコンパイル言語の違いは？

コンパイルされた言語と管理された言語を区別しようとすると混乱します。経験から、私はほとんどがコンパイルされた言語をC、C ++と見なし、マネージド言語はJava、C＃であると理解しています（明らかにもっと多くありますが、これらはほんの数例です）。しかし、2種類の言語の中心的な違いは何ですか？

私の理解では、使用する言語に関係なく、プログラムは基本的に低レベルのマシンコードに「コンパイル」されて解釈されるため、マネージ言語をコンパイル済み言語のサブセットにします（つまり、すべてのマネージ言語はコンパイルされた言語ですが、その逆ではありません）？

違いは「コンパイル済み」と「管理対象」ではなく、2つの直交軸です。「管理」とは、通常、ガベージコレクションされたメモリ管理の存在や仮想マシンインフラストラクチャの存在を意味します。どちらもコンパイルとはまったく関係がなく、人々がそれと反対だと考えるものは何でもありません。

単一のランタイムでマネージドメモリとアンマネージドメモリを混在させることは常に可能であり、コンパイルと解釈の違いも非常に曖昧であるため、このすべての「違い」は非常に曖昧で人為的で無関係です。

ウィキペディアを引用するには：

マネージコードとは、共通言語ランタイム仮想マシンの管理下でのみ実行される（バイトコードになる）コンピュータープログラムのソースコードを識別するためにMicrosoftによって作成された用語です。

マネージコードを実行するには、ランタイム（.NET CLTなど）が必要です。

区別する必要があると思いますが、必ずしも「コンパイル済み」と「管理済み」の間ではありません。これらは正反対ではありません。言語をコンパイルして管理しない、解釈する（コンパイルしない）および管理する、あるいはその両方、あるいはその両方を行うことができます。

「コンパイルされた」言語とは、開発者によって書かれたソースコードを、マシンによって実行されるより通常の「バイトコード」に変換するステップがある単純な言語です。「マシン」は、実際のプロセッサ、またはバイトコードを「ネイティブ」マシン命令に変換するための追加操作を実行する「仮想マシン」です。「コンパイルされた」言語の反意語は「解釈された」言語で、実行時にソースコードがバイトコード命令に変換され、コンパイルステップなしで実行される行ごとに変換されます。それらの間のハイブリッドは、「JIT」（Just In Time）からの「ジッター」であり、通常は実行マシンによる1回限りのステップとして解釈されます。

「マネージド」言語は、特定のランタイム環境内で消費されるプログラムを生成するように設計された言語であり、ほとんどの場合、バイトコードインタープリターが含まれます。プログラムのコードを受け取り、追加のマシンまたは環境固有の変換を実行する「仮想マシン」。環境には、「ガベージコレクター」などのメモリ管理や、スペースやツールの「サンドボックス」内でプログラムを動作させるためのその他の「セキュリティ」機能も含まれる場合がありますが、こうした機能は「マネージド」ランタイムの唯一のドメインではありません。実行される「ユーザー」コードの行の下でインタープリターを実行する必要があるため、実質的にすべてのインタープリター言語を管理対象と見なすことができます。さらに、JVMおよび.NET言語（Java、Scala、C＃、VB、F＃、IronWhatever）は、中間言語またはILにコンパイルされます。ILは、形式と機能がバイナリアセンブリ言語に表面的に似ていますが、「ネイティブ」命令セットに100％準拠していません。これらの命令は、JVMまたは.NETのCLRによって実行され、CPUアーキテクチャやマシンのOSに固有のネイティブバイナリ命令に効果的に変換されます。

そのため、一般的に、言語は「コンパイル済み」または「解釈済み」、「アンマネージド」（または「ネイティブ」）および「マネージド」と説明できます。可能性のある「解釈されたネイティブ」を除くこれらの任意の組み合わせとして記述できる言語があります（開発者によって書かれたものが実行されるものである手書き16進オペコードにのみ当てはまります）。解釈層を「実行時」（議論しやすく、議論しにくい）と見なす場合、すべての解釈言語は「管理」されます。

技術的になりたい場合、最近のマルチタスクOSを対象とするほとんどすべてのプログラムは「管理」されています。OSは、実行中の各プログラムに対して「仮想マシン」を作成します。プログラムは、実行中のプログラムのみであると認識します（または、少なくともそれ以外のことを知る必要はありません）。コードは、そのプログラムがメモリにロードされている唯一のものであるかのように、コード自体および他の参照ライブラリを呼び出します。同様に、データおよび制御デバイスを保存および操作するためにRAMおよびその他の上位メモリを割り当てる呼び出しは、メモリアーキテクチャ全体が利用可能であるかのようにコーディングされます。次に、VM（およびその背後のOS）は、さまざまなメモリポインターをプログラムの実際の場所、そのデータ、およびデバイスドライバーなどへのフックに変換します。どんなメモリでも アドレスXから開始し、プログラムはあたかもXがアドレス0であるかのように処理できるため、非常に安価ですが、プロセススケジューリングやプロセス間通信など、OSカーネルが担当する他のことがあります。管理が難しい。ただし、この基本パターンは一般に「管理」とは見なされません。プログラムは仮想マシンで実行されていることを知る必要がないため、多くの場合、割り当てられたメモリを「クリーン」に保つ責任があります。MS-DOSコマンドラインで実行するように設計されたプログラムは、MS-DOS環境がもうその下にない新しいWindows OSでも実行できます。代わりに、プログラムには「仮想コンソール」環境が与えられ、この「サンドボックス」から離れようとしない限り

マネージ言語は簡単に言えば、実行時にランタイム環境によって提供されるサービス（ガベージコレクションサービスなど）に依存する高レベル言語であるため、一般的にマネージドと呼ばれますが、それが使用する唯一のサービスではありませんこれらのサービスの一部は、.Net言語や、Javaのような「Java Virtual Machine JVM」を使用する仮想環境のように、実行security services, exception handling, standard typesに使用さCommon Language Run-time CLRれます。

アンマネージ言語は、仮想ランタイムサービスや中間言語などの中間言語を必要とせずにオペレーティングシステムによって直接実行可能な低レベル言語です。このような言語C, C++によって生成されるアンマネージコードは、OSに動的にリンクされるライブラリルーチンを使用して、呼び出されるDLL（ダイナミックリンクライブラリ）を実行するコード、アンマネージコードはメモリに直接アクセスするため、マネージコードよりも高速ですが、ハードウェアドライバーや洗練されたビデオゲームを構築する場合を除き、アンマネージ言語を実際に使用することは望ましくありません特にロール状態のような経験のない開発者と一緒に作業するのは危険ですwith great power comes great responsibility、そしてそれが開発者がシステムの底に飛び込むことなく拡張可能なコードを生成するのを支援するマネージド言語が存在する理由ですが、必要であれば混合コードを作成することができます、これらの記事はそれをすべて説明しています：

マネージ/アンマネージコードの相互運用性の概要

サンプル：アンマネージC ++、C ++ / CLI、およびC＃コードの混合