Discussion :

[amAtunisian]

Bonjour,
un programme écrit sous C# est transformé en CIL après sa compilation c'est à dire sous forme d'un bytecode , on m'a dit que le CIL ou MSIL est portable mais il faut que le CLR soit implémenté sur la machine pour qu'il soit interprété
ma question est : ce bytecode généré, peut-on l'exécuter sur une machine virtuelle JVM ou non ? et pourquoi pas ?
car une JVM interprète le bytecode non ?
merci beaucoup

[sevyc64]

LA CLR est exactement l'équivalent de la JVM. Les 2 sont des machines virtuelles qui transforme un bytecode en instructions exécutables sur une plateforme dédiée

La JVM interprète et exécute du bytecode Java, la CLR interprète et exécute du bytecode .Net appelé aussi IL ou MSIL.

Je ne pense pas que la JVM soit capable d’interpréter nativement du code IL, de même que la CLR n’interprète pas du bytecode java

[amAtunisian]

Merci beaucoup pour l'explication claire,
je croyais que le bytecode c'est du code comme le binaire , c'est à dire compréhensible par toutes les machines (ici la JVM) , je ne savais pas qu'il existait des bytecode java et des bytecode .NET
d'après wikipédia :" Il est contenu dans un fichier binaire "
mais je comprends pas comment peut - il être codé en binaire sans être copréhensible par la machine, c'est un peu flou pour moi

[BenoitM]

binaire ca ne veut rien dire.
le bytecode c'est des fichier binaire contrairement au sources qui sont des fichier text.
mais ce code binaire est ensuite interpreté par la JVM et traduit en instruction machine.
Comme un fichier word est un fichier binaire et est interpreté par word pour t'afficher un texte lissible.

ps : un fichier texte est aussi un fichier binaire mais son code ne fait que representer des caractères alphanumériques.

[amAtunisian]

Merci pour ta réponse,
J'ai compris maintenant que le bytecode est un fichier binaire qui ne s'exécute pas directement sur l'ordinateur mais il lui faut une JVM correspondante pour pouvoir l'exécuter. mais ce que je comprends pas maintenant c'est
la portabilité de C# par rapport à C et C++
C et C ++ : il faut recompiler le code source sur la nouvelle plateforme pour pouvoir l'exécuter
C# : il faut une JVM compatible pour pouvoir exécuter le bytecode généré (MSIL ou CIL)
je ne vois pas d'avantage ou de portabilité
par contre , je sais que grâce au CLR , l'exécution du code est plus sécurisée que le C/C++ (puisque la mauvaise manipulation des pointeurs peut causer des problème sur la machine ), de plus le JIT debugger qui permet de générer visual studio si un problème intervient dans un programme .NET

[sevyc64]

Alors C# n'utilise pas la JVM mais la CLR

Comme pour java, la portabilité est assurée (en théorie tout au moins) par le fait que le code source n'a pas besoin d'être recompilé sur chaque plateforme. Le bytecode produit à la compilation est censé fonctionné sur toutes les plateformes.

Bien entendu, il faut une machine virtuelle (JVM pour Java, CLR pour .Net) adaptée à chaque plateforme. Mais elle ne s'installe qu'une seule fois, il n'y a pas besoin de la recompiler à chaque fois.
Quand au bytecode, il est compilé en temps réel par la machine virtuelle lors de l’exécution, il n'y a pas besoin de recompiler à chaque fois.

Pour ce qui est de la réalité, tant que les programmes restent dans des utilisations génériques, la portabilité doit pouvoir être assurée, mais évidement s'ils font appel à des particularités spécifique à un os en particulier, la portabilité n'est plus assurée.

Personnellement, je n'ai jamais réellement testé la portabilité d'un code, que ce soit en C# ou en Java. Je ne sais donc pas si ça marche réellement

[amAtunisian]

il faut une machine virtuelle (JVM pour Java, CLR pour .Net) adaptée à chaque plateforme. Mais elle ne s'installe qu'une seule fois, il n'y a pas besoin de la recompiler à chaque fois.
Quand au bytecode, il est compilé en temps réel par la machine virtuelle lors de l’exécution, il n'y a pas besoin de recompiler à chaque fois.

Oui je vois maintenant une sorte de portabilité .

En ce qui concerne C#, il existe une CLR basique pour linux qui s'appelle Mono , qui n'est pas complète bien évidemment
ceci veut dire que si le programme comporte des fonctionnalités non couvertes par Mono , il pourra pas fonctionner