Java n'est pas un langage interprété. Il est compilé au vol, comme le C# et sur une application qui ne tourne pas 5 secondes, cela permet de faire des optimisations qui ne sont pas possible à faire (ou très difficile à faire) statiquement, ce qui donne au final un code qui est parfois plus rapide. De plus, certaines contraintes sémantiques de Java (ou de C#) font que certaines optimisations sont possibles dans ces langages et pas en C/C++ (en particulier à cause des pointeurs). Par exemple, on peut déterminer si les bornes d'un tableau sont respectées dans une boucle avant de l'exécuter, ce qui permet de supprimer les tests de débordement au moment de la compilation effective en code machine.
D'autre part, je ne vois vraiment pas le problème d'avoir un mélange de C et de Java, du moment que je ne vois pas le C quand je programme en Java. En fait, cela permet de faire ce qui est critique en C (voir en assembleur) et le reste en Java. Les progrès des machines virtuelles font qu'on a de moins en moins besoin de passer en C. Il y a quelques années, un jeu était programmé en C et en assembleur. De nos jours, on a un mélange Python pour les scripts, C++ pour le moteur de haut niveau, C pour attaquer OpenGL et de l'assembleur spécifique pour les shaders. A chaque problème son outil !
[^] # Re: Excellent
Posté par boubou . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 2.
Java n'est pas un langage interprété. Il est compilé au vol, comme le C# et sur une application qui ne tourne pas 5 secondes, cela permet de faire des optimisations qui ne sont pas possible à faire (ou très difficile à faire) statiquement, ce qui donne au final un code qui est parfois plus rapide. De plus, certaines contraintes sémantiques de Java (ou de C#) font que certaines optimisations sont possibles dans ces langages et pas en C/C++ (en particulier à cause des pointeurs). Par exemple, on peut déterminer si les bornes d'un tableau sont respectées dans une boucle avant de l'exécuter, ce qui permet de supprimer les tests de débordement au moment de la compilation effective en code machine.
D'autre part, je ne vois vraiment pas le problème d'avoir un mélange de C et de Java, du moment que je ne vois pas le C quand je programme en Java. En fait, cela permet de faire ce qui est critique en C (voir en assembleur) et le reste en Java. Les progrès des machines virtuelles font qu'on a de moins en moins besoin de passer en C. Il y a quelques années, un jeu était programmé en C et en assembleur. De nos jours, on a un mélange Python pour les scripts, C++ pour le moteur de haut niveau, C pour attaquer OpenGL et de l'assembleur spécifique pour les shaders. A chaque problème son outil !