Le C# est-il partiellement interprété ou réellement compilé ?

Question

Il existe de nombreuses informations contradictoires à ce sujet. Alors que certains disent que C# est compilé (car il est compilé en IL et ensuite en code natif lorsqu'il est exécuté), d'autres disent qu'il est interprété car il a besoin de .NET. Le Wiki de l'EN dit :

Beaucoup de interprétées sont d'abord compilés en une forme de code de machine virtuelle qui est ensuite virtuelle, qui est ensuite soit interprétée, soit compilée au moment de l'exécution en code natif.

Je suis donc assez confus. Quelqu'un pourrait-il m'expliquer clairement ?

Answer 1

C# est compilé en IL, par le compilateur c#.

Cet IL est ensuite compilé juste à temps (JIT), au fur et à mesure des besoins, dans le langage d'assemblage natif de la machine hôte. Il serait cependant possible d'écrire un runtime .NET qui interprète l'IL à la place. Même si cela était fait, je continuerais à dire que le C# est un langage compilé.

Answer 2

Un langage purement compilé présente certains avantages. La rapidité, en règle générale, et souvent la taille des ensembles de travail. Un langage purement interprété présente certains avantages. La flexibilité de ne pas avoir besoin d'une étape de compilation explicite qui nous permet d'éditer sur place, et souvent une portabilité plus facile.

Dans ce cas, une langue juxtaposée se situe dans une position intermédiaire.

C'est l'une des raisons pour lesquelles nous pouvons considérer qu'une langue jittée est soit compilée, soit interprétée, en fonction de la position que nous voulons atteindre sur la métrique, et de nos préjugés pour ou contre l'une ou l'autre.

C# peut également être compilé à la première exécution, comme c'est le cas dans ASP.NET, ce qui le rend proche de l'interprété dans ce cas (bien qu'il soit toujours compilé en IL et ensuite interprété dans ce cas). En tout cas, il présente pratiquement tous les avantages de l'interprété dans ce cas (par rapport au VBScript ou au JScript utilisé dans l'ASP classique), ainsi que la plupart des avantages du compilé.

Strictement, aucune langue n'est jittée, interprétée ou compilée en tant que langue. Nous pouvons transformer le C# en code natif (bien que s'il fait quelque chose comme charger dynamiquement un assemblage, il utilisera toujours l'IL et le jitting). On peut écrire un interpréteur pour C ou C++ (plusieurs personnes l'ont fait). Dans son cas d'utilisation le plus courant, cependant, C# est compilé en IL qui est ensuite jitté, ce qui n'est pas tout à fait la définition classique d'interprété ou de compilé.

Answer 3

Trop de sémantique et de déclarations basées sur l'opinion.

Tout d'abord : C# n'est pas un langage interprété ; le CLR et la JVM sont considérés comme des "runtimes" ou des "middleware", mais le même nom s'applique à des choses comme Perl. Cela crée beaucoup de confusion parmi les personnes concernées par les noms.

Le terme "interprète" faisant référence à un runtime signifie généralement que le code existant interprète un code non natif. Il existe deux grands paradigmes : L'analyse syntaxique lit le code source brut et effectue des actions logiques ; l'exécution de bytecode compile d'abord le code en une représentation binaire non native, dont l'interprétation nécessite beaucoup moins de cycles CPU.

À l'origine, Java était compilé en bytecode, puis passait par un interpréteur ; aujourd'hui, la JVM lit le bytecode et le compile juste à temps en code natif. Le CIL fait de même : le CLR utilise la compilation juste-à-temps en code natif.

Envisagez toutes les combinaisons de l'exécution du code source, de l'exécution du bytecode, de la compilation en mode natif, de la compilation juste à temps, de l'exécution du code source par un compilateur en mode natif juste à temps, etc. La sémantique de la compilation ou de l'interprétation d'un langage n'a plus de sens.

À titre d'exemple : de nombreux langages interprétés utilisent la compilation en bytecode juste à temps. C# compile en CIL, qui compile en JIT en natif ; en revanche, Perl compile immédiatement un script en bytecode, puis exécute ce bytecode à travers un interpréteur. Vous ne pouvez exécuter une assembly C# qu'au format bytecode CIL ; vous ne pouvez exécuter un script Perl qu'au format code source brut.

Les compilateurs juste-à-temps exécutent également beaucoup d'instrumentation externe et interne. Le moteur d'exécution suit l'exécution de diverses fonctions, puis ajuste la disposition du code afin d'optimiser les branches et l'organisation du code pour son flux d'exécution particulier. Cela signifie que le code JIT peut s'exécuter plus rapidement que le code compilé en mode natif (comme le C++ en général, ou comme le C# exécuté via IL2CPP), car le JIT adapte sa stratégie d'optimisation au cas d'exécution réel du code pendant son exécution.

Bienvenue dans le monde de la programmation informatique. Nous avons décidé de le rendre extrêmement compliqué, puis d'attacher des noms non descriptifs à tout. Le but est de créer des guerres de mots sur la définition de mots qui n'ont aucune signification pratique.

Answer 4

Si vous pensez, avez appris ou êtes de la vieille école, qu'un EXE compilé passe de la source au code machine, alors C# est interprété. Si vous pensez que compiler signifie convertir le code source en un autre code tel que le code octet, alors oui, il est converti. Pour moi, tout ce qui nécessite un traitement d'exécution pour fonctionner dans le système d'exploitation pour lequel il a été conçu est interprété.

Answer 5

Regardez ici : http://msdn.microsoft.com/library/z1zx9t92

Le code source écrit en C# est compilé dans un langage intermédiaire (IL) conforme à la spécification CLI.

(...)

Lorsque le programme C# est exécuté, l'assemblage est chargé dans le CLR, qui peut prendre diverses mesures en fonction des informations contenues dans le manifeste. Ensuite, si les exigences de sécurité sont satisfaites, le CLR effectue une compilation juste à temps (JIT) pour convertir le code IL en instructions machine en instructions machine natives.