Désolé, mais pour moi la limite est vraiment trop flou pour pouvoir dire "tel langage utilise une VM", "tel autre non".
Tu peux compiler du C# en natif (c'est prévu dès le départ)
Tu peux compiler du C++ en natif
Tu peux compiler du C# en bytecode .NET
Tu peux utiliser un backend .NET pour GCC
Un compilateur comme GCC utilise une représentation intermédiaire avant de transformer en code natif
Un compilateur comme mcs utilise une représentation intermédiaire avant que mono transforme en code natif.
Je préfères ma définition : une machine virtuelle est définie par un ensemble de jeu d'instruction différent du jeu d'instruction réel sur lequel s'exécute le programme.
En étant relativement portable, un langage comme C s'appui implicitement sur une certaine abstraction du code machine.
Dans tous les cas les processus d'exécution sont au final très proche, et ce qui change, c'est essentiellement la sémantique du langage (et donc l'ens
emble des optimisations que peut réaliser le compilateur) et l'ensemble des services sur lesquels se base le langage (et des langages comme C++ montre que même à "bas-niveau" il y en a).
Ta définition de VM (code intermédiaire nécessaire) me paraît trop réducteur. Je suis convaincu que l'on peut faire un compilateur C# qui génère directement du code machine.
Si le bytecode est une réalité et que le compilateur C# cible un bytecode, c'est d'abord une question de déploiement : il est plus simple de déployer du bytecode que 15 versions de ton exécutable pour les 15 plateformes que tu veux supporter.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tu peux compiler du C# en natif (c'est prévu dès le départ)
Tu peux compiler du C++ en natif
Tu peux compiler du C# en bytecode .NET
Tu peux utiliser un backend .NET pour GCC
Un compilateur comme GCC utilise une représentation intermédiaire avant de transformer en code natif
Un compilateur comme mcs utilise une représentation intermédiaire avant que mono transforme en code natif.
Je préfères ma définition : une machine virtuelle est définie par un ensemble de jeu d'instruction différent du jeu d'instruction réel sur lequel s'exécute le programme.
En étant relativement portable, un langage comme C s'appui implicitement sur une certaine abstraction du code machine.
Dans tous les cas les processus d'exécution sont au final très proche, et ce qui change, c'est essentiellement la sémantique du langage (et donc l'ens
emble des optimisations que peut réaliser le compilateur) et l'ensemble des services sur lesquels se base le langage (et des langages comme C++ montre que même à "bas-niveau" il y en a).
Ta définition de VM (code intermédiaire nécessaire) me paraît trop réducteur. Je suis convaincu que l'on peut faire un compilateur C# qui génère directement du code machine.
Si le bytecode est une réalité et que le compilateur C# cible un bytecode, c'est d'abord une question de déploiement : il est plus simple de déployer du bytecode que 15 versions de ton exécutable pour les 15 plateformes que tu veux supporter.