Reprise du message précédent :

 
La différence, c'est que le bytecode est quand même plus optimisé qu'un bête fichier de code en texte et que c'est dans la philosophie de Java d'être portable alors que le C a été développé pour Unix au départ.

Erreur :  contrairement a ce qu'on croit, le bytecode Java est tres peu optimise (on peu le desassembler et retrouver mot pour mot le code qu'on a tapé ou presque ... il remplace quand même "i = i + 1" par "i++" ).  
 
Pour sa part Eiffel optimise a un niveau "objet" avant de generer du C ... le C obtenu est donc déjà une version très optimisée de ton source objet. Sauf que c'est pas à un niveau physique (optimisation de boucle, etc etc) mais plutot à un niveau logique (resolution de type, etc etc). Il fait même beaucoup plus fort que C++ dans ce domaine. Au final (je dis ca un peu plus haut), dans le cas de projets importants Eiffel est plus rapide que C++
 

C'ets vrai, mais si on se cantonne a un certain sous ensemble de C, on se retrouve avec des progs completement portables : le legendaire 'printf("Hello, world!" )' fonctionne partout, par exemple. Comme je disais dans un post précédent, un source C généré par Eiffel peut être compilé sur une flopée d'OS sans problème ...

En fait, je trouve que la philosophie de traduire dans un autre langage pour compiler est dangereuse car on a 2 fois plu de chances d'avoir des erreurs de compilation (j'ai déjà fait l'expérience avec ADA et gcc sous solaris)

 
Ouais, mais 1) les mecs qui ecrivent des compilos commerciaux sont pas tous des manches et 2) y'a exactement le meme danger de generer du mauvais bytecode Java.
 
De toute facon, la quasi-totalite des compilos compilent (en interne) au moins une fois en un langage intermediaire (arbre semantique, code 3 adresses, etc) avant de generer le code final. La seule difference c'est qu'avec Eiffel, ce resultat de compil intermediaire est visible et lisible (enfin, faut s'accrocher quand meme )