Personnellement, je suis un adepte de C++ + QT. Et franchement, à part pour des application Internet, java ne fait pas le poids !Envoyé par Epictète
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Personnellement, je suis un adepte de C++ + QT. Et franchement, à part pour des application Internet, java ne fait pas le poids !
Le vrai pb de C++: la standardisation
Je crois que comme certain l'on peut être déjà dit (mais chui pas sûr), le vrai problème de C++ est le manque de biblio standard de haut niveau, et je trouve que là c'est un serieux problème, lorsqu'on doit par exemple maintenir un code qui a été écrit par une tierce personne, car la probabibilité qu'il ait utilisé une bibliothéque qu'on ignore totalement est beaucoup plus élévé qu'en Java. (ce qui va dimunier la productivité)
tout à fait mais cela ne se fait pas parce que les éditeurs d'OS se font la guerreVoir Java , Sun vs M$...
Si Sun et M$ se seraient mis d'accord sur un standard commun de telles biblios existeraient
Il y a de toute façon une abstraction trop faible entre la plateforme d'execution et le langage C++ pour que soit viable comme idée, au contraire du langage Java.tout à fait mais cela ne se fait pas parce que les éditeurs d'OS se font la guerre
Si Sun et M$ se seraient mis d'accord sur un standard commun de telles biblios existeraient
C++ est un langage, ni plus ni moins. Et Java est un langage qui s'accompagne d'un environnement d'execution ( sa machine virtuelle et son framework de classes ), son abstraction le lui permettant.
Comparer les deux, c'est un peu comme comparer la grammaire française et un dictionnaire anglais.
Alexis.
C'est n'est pas important l'ordre, tu peux même les apprendre les deux à la fois, mais en tenant compte qu'on parle de deux langues différentes.
Je me suis vu dans une glace hier, et c'était la première fois!
La nouvelle c'est que je ne suis que moitié homme, l'autre moitié et hors service!
PS: La partition de mon corps se fait verticalement!!
C++ vs Java un point de vue !!
Slt tt le monde,
je ss en retard pr rentrer ds ce sondage , et je n'arrive pas a lire tous les citations.
D'abord pour comprendre la diffrence entre les deux langauges de programmation évoluée C/C++ & Java il faut en jetter un coup d'œil ,et ca pr les deux langauges.
D'apres mn point de vue la diffrence se présente au niveau des bibliotheques standards disponibles. Java offre un ensemble des outils et fonctions prédéfinis qui gèrent des applications et des manipulations de grande taille vous pouvez remplcer une cinquantaine de lignes avec une seule instruction. Mais j'ai rencontré une diffeculté lors de mn premeir contact avec le Java c'est la manipulation des flux; j'ai pas trouvé des fonctions directes comme c'est le cas pour le C++ ou C.
Egalement une diffrence au niveau de la POO (Programmation Orienté Objet)
lorsqu'on parle de l'heritage (heritage multiple, class abstraite, fonction virtuelle,...) ;les conversion de types; la notion du pointeur (passage de parametres,..)
En C/C++ si vous vs ne metrisez pas la notion des pointeurs vous aurez des resultats étonnantes. En C/C++ il faut tous definir , n'exploiter pas la notion PAR DEFAUT mais en Java ca fonctionne.
En conclusion je voix qu'on peut comparer les langauges de programmation mais on peut pas dire que le mielleur c'est x ou y plutôt on peut spécifier un langauge à un certain type de programmation (Graphique, scietifique, ...).
Un language rapide ? IMPOSSIBLE !
A tout ceux qui prétendent "Java est plus rapide que le C++ sur certains programmes" (Entre autre j'ai aperçu le post de Badra qui parle de Fibonacci).
*STOP* Idée fausse :
Ce n'est pas le programme qui fait la vitesse de l'executable (tant que l'algorithme utilisé est identique dans les 2 languages) mais bien le compilateur lui-même !
Partant d'un même algorithme, plus un compilateur est efficace plus il trouvera d'optimisations et plus il saura choisir les instructions rapides pour la machine sur laquel vous êtes en train de compiler.
En Java, le compilateur a des contraintes plus importantes d'utilisation de la mémoire (vive ou morte) et surtout sur le temps de compilation "perdu" à chercher des optimisations spécifique a chaque architecture. Il est donc normal qu'un compilateur Java produise des executables moins rapide EN MOYENNE. (Cela n'exclut pas les nombreuses exceptions que vous avez pu rencontrer...)
Pour toutes les MV écrites en C/C++, il est toujours possible de "fusionner" votre programme Java avec le code source de la MV et d'élaguer toutes les parties inutiles du monstre optenu pour optimiser le tout. Vous obtiendrez ainsi un programme en C/C++ fatalement plus rapide que si vous aviez fait tourner votre code sur cette MV.
C'est discutable : pour la vitesse d'exécution d'un programme il y a plusieurs paramêtres qui rentrent en ligne de compte : la vitesse CPU et l'OS notamment.
S'il ya beaucoup de taches en exécution en même temps un programme développé en C++ risque d'être aussi lent qu'un autre fait en Java
Un programme subit les mêmes contraintes d'OS & vitesse CPU qu'il soit programmé en C++ ou en Java.
Oulà exemple très mal choisi, totalement en défaveur de tous les languages haut niveau justement !
La chute de performance étant exponentielle (quasi-asymptotique) lorsque l'on approche de la limite critique de l'utilisation d'un serveur, la moindre ressource utilisé en plus peut être fatale. Une attaque DDoS par exemple, vise à faire franchir au serveur cette fameuse "limite" au delà de laquelle tous les services du serveur sont perturbés (quasiment plus rien ne va répondre).
Ca s'explique très facilement :
Si a un moment donné tous les programmes sont soudainement ralentis, alors la quantité de programme en attente derrière augmente. Ce qui fait monter le nombre de ressource (en attente d'être utilisées) sockets, RAM, CPU, etc. La conséquence est que les ressources systèmes disponibles diminuent. Du coups les programmes actuellement en cours ralentissent aussi.
... Bref : moins on va vite, moins on va vite.
Les languages de haut niveaux comme le Java sont au contraire compétitif quand les ressources disponibles sont largement suffisante, c'est bien pour cela que tout le monde -en tout cas au moins moi- te dira que le Java est bien CAR les machines modernes sont de toutes façons de plus en plus puissantes (c'est à dire moins de chance d'approcher la limite critique).
Il faut quand même nuancer cela : le compilateur JIT (Just In Time) de la JVM n'effectue pas une compilation complète. Le gros du travail de la compilateur est bien fait par le compilateur javac, et le JIT n'a plus qu'à optimiser le code pour la machine.
De plus il a également ses avantages :
- Il connait avec précisions les caractéristiques de la plateforme qui fait tourner l'application, et peut donc utiliser les meilleurs optimisations.
- Il connait l'état du programme (classes chargées par exemple), et peut ainsi en profiter pour appliquer des optimisations qui ne serait pas toujours possible.
- Il peut recompiler du code déjà compiler afin de le "dés-optimiser" si possible. C'est très pratique car cela permet d'utiliser des optimisations très poussé et de revenir en arrière au cas où cela poserait problème !
Tout cela peut permettre d'améliorer les performances d'une application. Prenons l'exemple de l'inlining des méthodes :
- Un compilateur C++ ne pourra pas utiliser l'inlining pour une méthode virtuelle, puisque il faudra exécuter un autre code si elle est redéfini...
- Par contre, le compilateur JIT de la JVM pourra très bien utiliser l'inlining pour une méthode virtuelle, à condition qu'il n'existe aucune classes filles qui ne redéfinissent cette méthode. Et si une tel classe fille est chargé plus tard, le code sera recompilé afin de prendre en compte cela...
Bien sûr je ne dis pas qu'un programme Java sera obligatoirement plus rapide qu'une programme C++. Je dis seulement qu'un programme Java peut tout à fait rivaliser avec un programme C++ en terme de performance. Bref je reste persuadé que l'argument "performance" ne devrait pas entrer en compte dans le choix du langage (en tout cas pour ce qui concerne C++ et Java).
Et ceci n'est pas forcément vrai non plus !!!
J'avais fait quelques tests il y a quelques temps avec GCJ et JET (qui permettent tout deux de générer du code natif) et grosso modo les performances natif se trouvait entre la JVM -client (JVM "standard") et la JVM server (JVM optimisé pour les gros traitement) : La machine virtuelle Java est-elle vraiment lente ?
a++
très intéressant, mais il faut aussi signaler quelques détails sur cette compilation JIT :
+ la compilation bénéficie d'informations sur l'état de l'environnement d'exécution, ce qui n'est pas possible avec les compilateurs traditionnels
+ ce compilateur JIT ne traite pas tout le code d'un coup, ce qui implique qu'il ne peut pas, contrairement aux compilos traditionnels, appliquer certaines optimisations très poussées sur le code... qui peuvent réduire sa taille, et augmenter sa vitesse énormement
+ le fait que le code compilé puisse etre facilement "dé-compilé", comme tu le soulignes, implique que la structure du code compilé est restée assez proche d'une structure de bytecode.... et donc que les optimisations n'ont pas été appliquées à leur potentiel maximal
(nb: ceci va en revanche beaucoup dépendre de l'architecture de la machine... car le bytecode java possède quand meme pas mal d'instructions bas niveau
très intéressant... sauf qu'il faut savoir que cette compilation JIT et l'inlining ont un cout, qui n'est pas négligeable surtout si l'on passe son temps à changer de "classe réelle" pour cette méthode
J'avoue que je ne sais pas vraiment comment cela fonctionne en détail... mais cela ne pourrait pas être effectué par le compilateur javac ?+ ce compilateur JIT ne traite pas tout le code d'un coup, ce qui implique qu'il ne peut pas, contrairement aux compilos traditionnels, appliquer certaines optimisations très poussées sur le code... qui peuvent réduire sa taille, et augmenter sa vitesse énormement
Non le compilateur peut compilé en natif pure même s'il doit le "décompiler". En fait le code natif n'est pas vraiment "décompilé" mais plutôt supprimé pour être recompilé à partir du bytecode lorsque la JVM charge une classe qui pourrait poser des problèmes (plus d'info, même si c'est un peu vieux : Method Inlining Example).+ le fait que le code compilé puisse etre facilement "dé-compilé", comme tu le soulignes, implique que la structure du code compilé est restée assez proche d'une structure de bytecode.... et donc que les optimisations n'ont pas été appliquées à leur potentiel maximal
Sinon si le sujet t'intéresses tu peux jeter un coup d'oeil à ce billet qui recense quelques optimisations possibles par le JIT (même si certaines sont théoriques et ne sont pas encore implémenté) : Software Territory: Where Hardware can't go!
Les optimisations d'un programme C++ et Java ne se situent pas au même endroit ni au même moment
a++
Pas du tout les ressources sont gérées par l'OS ; qu'un programme soit en Java ( bytecode ) ou en C++ ( code natif ) l'OS lui fournit la mémoire requise.
Quand tu fais un new c'est l'OS qui fournit la mémoire donc il n'ya pas de compétition comme tu affirmes avec Java..
Sinon si le sujet t'intéresses tu peux jeter un coup d'oeil à ce billet qui recense quelques optimisations possibles par le JIT (même si certaines sont théoriques et ne sont pas encore implémenté) : Software Territory: Where Hardware can't go!
elles ne se situent pas au même endroit, car java a surtout oublié d'en faire
edit par ailleurs, il y a de nombreux que peu de gens prennent en compte... comme le nombre d'instructions exécutées pour une instruction utile dans une machine virtuelle, contrairement à un code 100% compilé qui effectue chaque instruction "utilement" (cf papier de riccardi sur les machines virtuelles)
perso, j'ai pas besoin d'aller voir ce papier... j'ai les sources de la machine virtuelle java officielle : elle fait partie intégrante de mon stage, donc je peux affirmer connaître un peu
Si on pouvait éviter de partir en troll ce serait bienelles ne se situent pas au même endroit, car java a surtout oublié d'en faire
Et qu'est-ce que tu appelles une instruction utile exactement ?
Il y a quelques années un débat similaire avait lieu entre le C et le C++ trop lourd à cause de ses concepts objets...
Faudrait-il s'en passer pour n'avoir que des instructions "utiles" ?
(au passage je n'ai pas retrouvé ce papier de riccardi sur les machines virtuelles... si tu a un lien j'y aurais bien jeté un coup d'oeil
a++
pas du tout...
je parle d'instructions utiles au sens d'instructions exécutées pour faire le boulot du programme...
contrairement à celles qui sont ajoutées pour faire le boulot de la machine virtuelle
http://citeseer.ist.psu.edu/rd/43437...optimizing.pdf(au passage je n'ai pas retrouvé ce papier de riccardi sur les machines virtuelles... si tu a un lien j'y aurais bien jeté un coup d'oeil
Le boulot de la machine virtuelle est justement de laisser le développeur se concentrer sur le code métier... je ne pense pas que ce soit inutile !pas du tout...
je parle d'instructions utiles au sens d'instructions exécutées pour faire le boulot du programme...
contrairement à celles qui sont ajoutées pour faire le boulot de la machine virtuelle
(Je comprend pourquoi je ne trouvais pas, je cherchais une message de riccardi sur le forum)
Ca à l'air intéressant et j'essayerais d'y jeter un coup d'oeil quand j'aurai le temps... mais ce n'est pas vraiment d'actualité : ca date de 1998 (et donc de Java 1.2, la première JVM de Sun à intégrer un compilateur JIT). 9 ans après les techniques des JIT ont quand même évoluées...
a++
rien à voir...
la machine virtuelle permet surtout d'avoir normalement le meme code sur différentes architecures physiques différentes, mais peuvent parfaitement etre très bas niveau, et obliger le développeur a comprendre le RTL de la machine
(Je comprend pourquoi je ne trouvais pas, je cherchais une message de riccardi sur le forum
Ca à l'air intéressant et j'essayerais d'y jeter un coup d'oeil quand j'aurai le temps... mais ce n'est pas vraiment d'actualité : ca date de 1998 (et donc de Java 1.2, la première JVM de Sun à intégrer un compilateur JIT). 9 ans après les techniques des JIT ont quand même évoluées...
je sais parfaitement qu'elles ont évoluées, et j'ai d'ailleurs des papiers beaucoup plus récents (normal, c'est mon domaine d'étude), mais ce papier reste une référence... ce qui y ait écrit est valable pour toutes machines virtuelles à jeu d'instructions assez bas niveau
la grosse différence entre Java et C++ c'est que la couche objet pour C++ tu as des pointeurs "live" pour accéder directement à la mémoire : un jmp ou mov <adresse> ,valeur ou registre en assembleur c'est direct ça consomme pas forcément beaucoup de cycles CPU donc la différence entre C et C++ peut être minime.Si on pouvait éviter de partir en troll ce serait bien
Et qu'est-ce que tu appelles une instruction utile exactement ?
Il y a quelques années un débat similaire avait lieu entre le C et le C++ trop lourd à cause de ses concepts objets...
Faudrait-il s'en passer pour n'avoir que des instructions "utiles" ?
a++
En java c'est radicalement différent c'est du pseudocode à réinterpréter , faut vérifier s'il n'y pas d'exceptions , s'il n'ya pas d'erreur mémoire avec le Garbage Collector....donc tout cela ça fait beaucoup de traitement...
Attention a tout ce qui est idées reçues sur la gestion mémoire dans la JVM et coût du GC sur les perfs :
Brian Goetz qui fait beaucoup contre les mythes Java à dit :
http://java.sun.com/developer/techni.../goetz_qa.html
Le reste de l'interview est très interessant aussi.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager