Developpez.com - Rubrique Java

Le Club des Développeurs et IT Pro

Le débat C++ vs Java fait toujours rage

Le 2003-01-09 02:13:51, par aliasjcdenton, Membre régulier
Quels sont les avantages et les inconvénients respectifs majeurs des langages de programmation C++ et Java l'un vis-à-vis de l'autre ?

  Discussion forum
1911 commentaires
  • Elrond
    Membre régulier
    C++ est plus complet (on peut a peu pres tout faire avec), plus performant (quand correctement concu et code), plus generaliste(bien que en principe objet, on n'est pas oblige de faire de l'object avec), plus puissant (template, ...), plus complet (il vit depuis longtemps et possede de tres nombreuses librairies, standard ou non). C'est egalement un langage tres complique et tres sujet a l'erreur et a l'introduction de bogues.

    Java est plus facile a apprendre et utiliser, plus portable, plus objet.

    Dans les deux cas il peut y avoir des problemes de compatibilite. Au niveau C++, c'est surtout lie a la portabilite (si tu code du C++ standard), mais le code est ensuite rarement compatible, sur une meme machine , d'un compilateur a un autre. Au niveau Java, il y a des problemes de compatibilite et support entre les versions. La version 2.0 de Java n'est pas supportee partout et par tous.
    le 09/01/2003 à 10:43
  • koala01
    Expert éminent sénior
    Envoyé par kisitomomotene
    Vue sous cet angle, le C est largement préféré au C++ par la communauté des développeur lorsqu'on veut faire un développement "proche de la machine" . Le C++ a finalement de la peine a trouver sa véritable place, quelque soit le critère de choix que l'on opte (productivité, performance, robustesse, maintenabilité etc) on pourra difficilement choisir le C++ comme langage pour démarrer un nouveau projet, et il ne sera finalement utilisé que pour maintenir du code ancien
    Je ne suis pas sur du tout!!!

    Il ne faut pas croire que, parce que l'on dit "proche de la machine", on parle d'office de drivers, non plus

    Je travaille actuellement sur un projet industriel entièrement écrit en C++ qui n'a été démarré il n'y a "que" 5 ans

    Je ne doute pas qu'il y aurait sans doute moyen de faire le même projet en java, mais je ne suis pas sur du tout que nous pourrions atteindre le degré de performances obtenu en C++

    Dans certaines situations, le recours au garbage collector ou à une machine virtuelle (ou à d'autres obligations apportées par java) n'est, purement et simplement, pas envisageable, mais où l'apport du paradigme OO ou du paradigme générique est indispensable.

    Dans de telles situations, le seul langage qui reste, c'est C++

    La place de C++ est relativement simple : entre le driver et l'application qui peut se permettre de recourir à une machine virtuelle

    Et encore, il y a parfaitement moyen de décider d'écrire un driver avec
    le 11/02/2012 à 10:54
  • Logan Mauzaize
    Rédacteur/Modérateur
    Le JCP a tout de même son gros effet pervers : le lobbying.

    Jusqu'à récemment, il n'était constitué que d'industriel qui crééait surtout des JSRs pour mettre en avant leur propre produit. Car il y a une chose qui très forte mais qui créé tout le lobbying, toute JSR doit être accompagnée d'une implémentation.
    On en veut pour preuve le problème avec Jigsaw/OSGi, Closure/Lamba Expression/etc, ou même l'API de cache de Red Hat...

    Ensuite avoir un comité de pilotage implique une forte lenteur des changements puisqu'il faut que la moitié des membres aillent dans le même sens. Le langage n'évolue pas énormément, malgré toute l'envie qu'il y a de toute part (utilisateurs, JUG leaders, industriels, etc.). On voit bien de nouvelles fonctionnalités s'ajouter mais peu de choses en place qui évolue.

    Un autre point noir pour Java et une des fameuses règles qui finira sûrement par tuer Java si elle n'est pas brisée d'ici les 2-3 prochaines versions majeurs : la rétrocompatibilité binaire. La règle qui tue tout, comme avoir des génériques uniquement "compile-time". Aucun intérêt puisque la compatibilité de l'API n'est pas garantie.

    Concernant l'investissement de Sun dans Java, il ne faut pas oublié qu'une part importante des développeurs et des technologies intégrés dans Java ne sont pas de Sun mais d'Apache, IBM, Xerox, Red Hat et autres.

    Aujourd'hui la seule force de Java c'est d'avoir été là et relativement bon avec une courbe d'apprentissage très rapide au moment de la bulle Internet. Tout comme COBOL dans les années 70-80. Franchement, il y a un paquet de langage que je préfère à Java. Cependant Java n'a aucune niche, donc il est voué à mourir s'il ne se met pas au niveau de langage plus évolué. Ou alors l'avenir se jouera sur des langages alternatifs comme Groovy et Scala. Comme C# l'a été pour la plateforme Microsoft en remplacement de VB et C++.
    le 26/10/2012 à 9:28
  • gRRosminet
    Membre confirmé
    Java et C++ sont deux langages distincts (bien que très semblables) et n'ont pas les mêmes objectifs. En effet, pour faire ton choix entre les deux cela dépend de ton objectif et de tes contraintes (support, nombre d'utilisateurs, portabilité, ...)
    le 09/01/2003 à 10:00
  • _skip
    Expert éminent
    Envoyé par SuperBidi
    J'ai souvent vu ça :

    while (true)
    {
    try
    {
    Ma boucle principale
    }
    catch (Exception e)
    log e;
    }

    Le gros avantage étant que ça marche, va juste y avoir un traitement d'ignoré, basiquement, un message client->serveur non traité, ou un click souris d'annulé, mais ça ne mets pas toujours en danger la stabilité du soft.
    Par contre... ça encourage à ne pas corriger l'erreur si celle ci ne génère aucun effet visible et que son taux de reproduction est minime.
    Le résultat étant que toutes les prochaines erreurs deviennent silencieuses, en ce sens qu'elles génèrent le même log. Et y a un moment ou le soft devient ingérable.
    Hein?
    Il y a surtout un moment où le développeur doit se remettre en question. Dans ma boîte, le type qui écrit un catch(Exception) sans une très bonne raison est assuré de passer par la case goudron et plumes.
    Tu peux pas mettre des lacunes aussi évidentes de gestion d'erreur sur le dos d'un langage. Dans ce cas que tu montres, ce n'est même pas un truc subtil qu'on pourrait faire sans faire gaffe, mais une faute de conception grossière.

    Envoyé par SuperBidi

    Après, ça peut passer pour un défaut de conception, même si dans certains cas je le pronerai (sur un serveur, c'est même un raccourci génial, tu sais que si un traitement plante bizarrement, ton serveur continue de tourner). Mais il faut derrière absolument que les dévs corrigent l'intégralité des bugs générés, et ça, c'est pas toujours donné.
    Depuis quand le but d'une gestion d'exception est de laisser continuer l'application coûte que coûte dans un état indéfini et potentiellement instable? Le but d'une exception n'est pas de jeter sous le tapis des erreurs potentiellement graves pour donner un faux sentiment de stabilité.
    Franchement je peux pas être d'accord avec ton point de vue. Et je maintiens que catcher une exception au hasard sans être sûr de pouvoir la gérer tient du vice.

    En fait je vais te le dire, ne le prends pas mal mais à mon avis, comme beaucoup de développeur, tu ignores comment les exceptions doivent s'utiliser.
    le 08/09/2011 à 10:51
  • jabbounet
    Membre expert
    Envoyé par kisitomomotene

    Et si dans une application les paradigmes C++ ne posent pas de problèmes, il est fort probable qu'on aurait pu obtenir les mêmes résultats mais avec plus de productivité, de robustesse ou de portabilité si on avait utilisé C# ou Java par exemple.
    C# portable, pas vu sur HP-ux, sun/solaris,...?

    C et C++ sont parfaitement portable si tu as tu t'impose une certaine discipline que t'impose d'autres technos.

    java peu ne pas être supporté par certains matériels spécifiques si aucune jvm n'a été porté sur ce type de palteforme, et si tu sors des standards tu peux avoirs soucis avec la porta comme pour les autres langage.
    exemple utiliser des trucs dans java.sun.misc et ensuite devoir porter ton application sur une jvm non différente de celle de sun (oracle maintenant)
    le 11/02/2012 à 16:51
  • ptah35
    Membre éclairé
    Envoyé par el_slapper
    sur le style et la syntaxe. Chacun a sa préférence, mais il y a des gens pour qui l'un est insupportable, et l'autre absolument génial. Certains qui vont trouver l'un inqualifiable, et l'autre parfait. En fait, c'est juste une question d'habitude. Mais quand les habitudes sont bien ancrées, difficille de passer de
    Code : 
    1
    2
    3
    If Blabla Then
    Blibli
End If
    à
    Code : 
    1
    2
    3
    if(Blabla){
    Blibli
}
    Je me souviens que lorsque j'étais étudiant, je détestais PASCAL pour la même raison, je ne jurais que par le C . Mais après une vingtaine d'années à travailler avec différents langages non seulement impératifs, mais également fonctionnels, je ne me soucie plus de ce genre de détails... un bloc est un bloc qu'il s'écrive entre accolades ou entre un begin et un end ou même par la simple indentation...
    le 15/05/2014 à 19:51
  • goethe
    Membre du Club
    C++ beaucoup plus rapide que java.
    java beaucoup plus portable que C++.

    pour toi nouveauté de programmation :
    - Le C++ n'est pas tout objet
    - les pointeurs !
    le 09/01/2003 à 8:55
  • kpouer
    Membre confirmé
    Oui en java il y a 2 types d'exceptions : les checked exceptions et les unchecked exceptions.
    Les checked on est obligé de les catcher et de prévoir un traitement, les unchecked sont sensé ne pas arriver et donc il n'est pas obligatoire de prévoir un traitement.
    Si une exception n'est pas catchée par l'appelant de la méthode qui l'envoie, il faut signaler qu'elle sera envoyée au dessus. Ainsi on est sur qu'elle sera traitée à un moment ou à un autre (choisi par le développeur).
    Ce genre de boucle peut paraître idiote, mais si on ne sait pas comment est le reste du programme on ne peut rien en déduire.
    Si c'est un serveur, l'important est qu'en toute circonstance ce dernier fonctionne et ne plante pas totalement au premier imprévu.
    Après dans les logs de ton catch tu traces suffisamment pour être capable de savoir ce qui s'est passé et corriger le bug.
    Sachant qu'en principe ce genre de catch ne doit attraper que les unchecked exceptions (NullPointerException par exemple que l'on ne doit jamais catcher car si elles arrivent il s'agit d'un bug), OutOfMemoryError en cas de dépassement mémoire, ce qui peut arriver sans que ce soit un bug).
    En tout cas il vaut mieux que le programme retombe sur ses pieds si possible plutôt que le planter totalement.
    le 08/09/2011 à 11:06
  • kpouer
    Membre confirmé
    SuperBidi, en java on teste si une référence est null, car il est possible qu'un champ d'un objet soit null (si c'est un objet et que tu ne l'as pas initialisé c'est sa valeur par défaut).
    Et on peut ne pas avoir systématiquement besoin d'initialiser un champ, peut être qu'on va l'initialiser lors de sa première utilisation d'ou le test à null.
    En C++ si tu n'initialise pas ton champ il a la pire des choses, une valeur indéterminée. Ca ne va même pas t'empêcher d'utiliser ce champ et même d'appeler des méthodes dessus, ça ne plantera que lorsqu'une méthode tentera d'accéder à un objet de la classe, et ça le fera à l'exécution.
    En java c'est impossible, si tu appelles un méthode sur une variable null, tu as immédiatement un NullPointerException et tu sais que tu as un bug.

    Envoyé par GanYoshi
    A rien, à ce que j'ai compris les RuntimeException ne sont généralement pas sensées être catchées puisqu'elle ne sont pas sensés se produire.

    Par contre on peut lever une CheckedException si le test de nullité est vérifié.
    Si, ça sert, mais dans des cas exceptionnels. Tout dépend si tu veux que ton programme plante en cas de bug ou si tu veux qu'il continue à tourner.
    Tu écris Tomcat par exemple, lorsqu'une page web est appelée, Tomcat appelle la servlet correspondante, il est très probable qu'ils catchent tout, parce qu'ils ne maitrisent pas le code de la servlet (puisqu'il est fourni par un tiers), il ne faudrait pas qu'un bug dans la servlet ferme totalement Tomcat.
    le 12/09/2011 à 21:17
  Poster une réponse