Java vs C++

[brice.wernet]

Suite à une remarque sur un de mes commentaires, je vais développer ici ce que je trouve à Java, VB .Net et C# face à C++.

C++ est un langage puissant, permettant de faire de nombreuses choses: héritages multiples, généricité, macros... Ceci mène à différents styles de programmation: un par personne.

C++ est un langage standardisé. Mais aucun complateur ne suit parfaitement le standard. Certains passent outre certaines constructions et fonctionnalités. Ce qui mène à ceci: vous planchez sur votre programme. Vous lisez un bouquin C++ basé sur le standard en vous disant: comme cela, je suis sûr que ça marche. Vous commencez à implémenter, vous compilez, mais comme votre compilateur correspond au standard truc muche de 1997 et que vous utilisez une construction du standard machin chose de 1998, vous êtes dedans.

C++ est un langage seul. Si vous voulez un environnement de développement, vous avez le choix, et vous passez du temps dessus: C++/STL/SDL? Mais quelle STL? Celle de Microsoft est buggée, celle de GNU force la GPL...

C++ permet beaucoup de choses, et finalement on passe son temps à corriger des bugs débiles ou à chercher la construction la mieux ("optimisation")

C++ nécessite de se concentrer beaucoup sur certains problèmes (mémoire, taille des tableaux)

C++, sauf à activer le typage dynamique, ne fait que du typage statique. Et autant pour la modularité et la reflctivité.

Les autres langages dits "récents", basés sur une machine virtuelle:

- sont standardisés. Et leurs compilateurs suivent des standards stricts (ou alors, c'est procès)

- sont fournis dans un environnement complet et plutôt cohérent

- viennent avec une documentation exemplaire

- ont appris à utiliser les construction les plus utiles (pas d'héritage multiple, source de pas mal de bugs)

- viennent en général avec une belle convention d'écriture

- on rattrapé leur retard en termes de performances

D'autre slangages, tels qu'objective-C et Eiffel, ont aussi la plupart de ces qualités, et sont compilés en natif. eiffel est un peu différent, il permet des choses intéressantes au niveau statique (portée des méthodes et attributs définie classe par classe si on veut)

Ces langages permettent de s'abstraire encore de différents niveaux.

Je reconnais que C++ est utile, mais limiter osn usage aux endroits ou sont utilité est cruciale permet de gagner énormément de temps. Par exmeple, on peut penser que Microsoft va refaire ses systèmes ainsi: C/assembleur dans le noyau, C++ pour la VM et certains composants de base, .Net pour les applis.

Plus les langages avancent, plu on va vite à créer des applis de plus en plus complexes.

Petite note finale: Fortran est un langage qui apporterait à être réutilisé, notamment pour programmer les SIMD ou les shaders. Comme quoi je pense que chaque lagage est utile, mais que certains nécessite plus d'efforts que d'autres dans certains domaines.

[Sentinel]

Le langage C++ est effectivement extrêmement buggé et difficile d'utilisation (si l'on veut programmer proprement, j'entends).

Je vous suggère une lecture extrêmement intéressante, écrite par un vrai gourou du C++. Il suffit d'envoyer un mail à :

cline-cpp-faq-html-zip@crynwr.com

(ce que vous mettez dans le Sujet et le corps du mail n'ont aucune importance, c'est un bot de réponse). Vous recevrez la FAQ par retour de mail.

[brice.wernet]

Le langage C++ est effectivement extrêmement buggé et difficile d'utilisation (si l'on veut programmer proprement, j'entends).

Je ne crois pas que le lanage soit buggé. C'est surtout que les compilateurs sont plus ou moins compatibles.

quand à la difficuté d'utilisation, on peut utiliser une norme de programmation (comme ELEMTEL), mais au final, on se demande pourquoi utiliser C++ qui impose en plus la gestion de la mémoire.

C++ permet par contre de se créer sa propre boite à outils de développement parfaitement calibrée. Mais c'est long.

Disons que pour la plupart des produits, la complexité d'un langage comme C++ rend le produit plus cher à créer et à maintenir.

[TotosssFR]

Bonjour :)

Je trouve que les nouveaux langages du type java ou .net sont très simples à utiliser et permettent de raccourcir de manière conséquente les durées de développement.

Je travaille actuellement au codage d'une application en Java et je trouve vraiment que ce langage est très bien pour de nombreuses raisons (code propre, gestion des exceptions très simple ...). De plus, les technologies dévellopées autours de ce langage sont très intéressantes comme les JavaBeans, les serveurs d'applications et les objets distribués avec JavaRMI.

Malheureusement, Java possède un énorme défaut : il est extrèmement lent à l'exécution de l'ordre de 5 fois plus lent que le C++ en moyenne. L'utilisation du langage Java ne peut donc pas être utilisées dans des programmes nécessitant beaucoup de ressources en calcul ou dans les systèmes temps réel. Pour ces types d'application, on préferera Fortran ou C++.

Tout ça pour dire que j'aime beaucoup développer en Java mais que je préfère de loin créer mes applications en C++ pour la vitesse d'exécution.

[brice.wernet]

Malheureusement, Java possède un énorme défaut : il est extrèmement lent à l'exécution de l'ordre de 5 fois plus lent que le C++ en moyenne.

Tout dépend de ce que tu programmes. Si ton programme c'est de l'UI+base de données, le Java convient très bien et n'est pas plus rapide ou plus lent que le C++ (on arrive difficielemt à mesurer).

Si ton programme fait des calculs intensifs, le C++ est plus rapide (et fortran encore plus).

Ce que je reproche le plus à Java et aux langage à garbage collecotr en général, c'est l'impossibilité de prédire quand le GC va démarrer. J'avais fait un test sur un programme créant plein de petits objets qui se pointaient entre eux (c'est pas beau). Sur java 1.2, la machine a fait un beau garbage collect de plus d'une minute sans plus rien faire d'autre.

Mais par exemple, certains algo nécessitant la création rapide d'objets peuvent aller plus vite en Java qu'en C/C++, suivant le compilateur utilisé (il me semble que le compilo microsoft n'est pas rapide en allocation mémoire, celui de Borland l'est plus). C'est au moment de libérer les ressources que ça devient plus drôle.

[glenux]

Bonjour :)

Malheureusement, Java possède un énorme défaut : il est extrèmement lent à l'exécution de l'ordre de 5 fois plus lent que le C++ en moyenne. L'utilisation du langage Java ne peut donc pas être utilisées dans des programmes nécessitant beaucoup de ressources en calcul ou dans les systèmes temps réel. Pour ces types d'application, on préferera Fortran ou C++.

Tout dépend d'avec quoi tu compile. Il me semble qu'il existe un compilateur java créant un "vrai" executable (et donc pas du byte-code pour la JVM).

Dans ce cas la, cette comparaison ne tient plus la route...

[brice.wernet]

Tout dépend d'avec quoi tu compile. Il me semble qu'il existe un compilateur java créant un "vrai" executable (et donc pas du byte-code pour la JVM).

Dans ce cas la, cette comparaison ne tient plus la route...

Il y en a plusieurs, dont gcj, qui fait partie de gcc. Mais on ne peut pas compiler n'importe quel bytecode, tout dépend des fonctions utilisées. De plus, le résultat n'est pas meilleur qu'avec les meilleurs JIT.

[fabricer]

Il y a quelques idées reçues à corriger dans ce que vous dites :

- C++ est buggé : non, seuls les compilateurs sont buggés. Mais le plus gros problème en dehors des bugs compilateur est que par essence puisque la gestion de la mémoire est confiée au développeur, programmer en C/C++ est forcément générateur d'un risque industriel conséquent.

Même au sortir d'une phase de qualification technique longue et rigoureuse, un gros prog en C/C++ n'est jamais fiable et procure du stress à tout chef de projet ;-)

- Java est plus lent : faux, tout du moins en partie. D'une part chaque implémentation de JVM (SUN, IBM etc) donne des perfs différentes, il faut donc tester et comparer en fonction des avantages de chacunes. Ensuite les JVMs intègrent désormais la technique de compilation à la volée, autrement dit du code natif est généré pour les parties de code exécutées la première fois. Donc le démarrage est lent, mais potentiellement une application de gestion Java tournera aussi vite qu'une appli native équivalente dès que le démarrage est passé.

Pour ce qui est de certaines applis de calcul pure, je n'ai pas eu l'occasion de vraiment tester, mais a priori les différences ne sont pas dues au fait que le bytecode soit interprété puisque maintenant il est exécuté en natif dans les JVMs.

Par contre pour des raisons évidentes de portabilité les JVMs intègrent des couches de librairies qui pourraient éventuellement poser des pbs de perfs dans ce domaine.

Mais il n'est pas inimaginable de pouvoir trouver des JVM's optimisées pour le calcul.

- Java est plus propre que C++ : par essence oui , on programme plus proprement en Java. Mais attention aux illusions, Java est syntaxiquement simple mais il permet en objet de faire des choses aussi complexes que C++. Mais un mauvais développeur en C++ le restera en Java, la simplicité du langage ne fait jamais que l'on programme mieux. Si on n'est pas capable de faire correctement du multi-threading en C++ par example, on y arrivera pas mieux en Java.

La simplicité de Java fait que certains ont tendance à se relâcher et à coder aussi cradement qu'en C++, ce n'est pas plus permis en Java qu'ailleurs...

- Java ne nécessite pas d'optimisation : peut être la pire des idées reçus. Si vous travaillez sur des projets ambitieux, à haute disponibilité, vous devez faire attention à tout : bannir les allocations d'un grand nombre d'objets ou de buffers/objets trop volumineux, sinon vous vous retrouvez avec des bottleneck d'allocation mémoire ou vous risquez de voir la JVM vous exploser à la figure. Le fait de ne plus s'occuper de pointeurs ne doit pas faire oublier les bonnes habitudes : économiser les ressources. Il y a également des techniques qui permettent de faciliter l'accès aux objets en mémoire pour la JVM, et également de jouer sur la réutilisation de buffers/objets déjà alloués.