Citation:
Envoyé par zais_ethael
J'ai vraiment envie de me contenter d'affirmations.
Je signale si ce n'etait pas clair que mon intervention etait essentiellement due a la portee enorme de ton affirmation.
Citation:
Bon, en vrac:
- vision de l'orienté objet beaucoup plus proche du pur concept objet
Tu commences bien, par un defaut. Le paroxisme du pur objet chez moi, c'est de devoir heriter d'une classe Math pour pouvoir calculer un sinus (ce que fai(sai)t Eiffel). L'OO, c'est essentiellement une technique de conception qui, comme toutes les techniques de conceptions, a ses limites.
Citation:
- immense portabilité (ralala, je sens qu'on va encore me copier coller LE truc ultra rare qui prouve un exemple de non portabilité du java)
Write-Once, Debug everywhere, c'est ca? Je me demande pourquoi certains logiciels imposent de tourner avec la JVM qu'ils fournissent.
Citation:
- api standard très fournie, les seuls langages qui égalent + ou - le java sur ce point sont le C# et le Delphi. Pour le C++, on peut dire qu'il est vraiment tout en bas de l'échelle, la stl ne contient à peu de choses près que des conteneurs, des streams et... des chaines de caractères (8O wow, c'est révolutionnaire).
En quoi une API standard (en passant, pour l'interface graphique, le standard c'est AWT, Swing, SWT ou les bindings GTK ou QT?) augmente-t'elle la productivite dans tous les cas. Je rappelle que tu avais ecrit toujours et que c'est toi qui a souligne. Des infrastructures non standards mais mieux adaptees au probleme peuvent etre plus productives. Ces infrastructures existent pour moi en C++.
Citation:
- edis extrèmement puissants, avec nottament de la rédaction de code automatique et du refactoring comme j'en ai jamais vu dans aucun autre langage. C'est quelque chose de pratiquement impossible à créer en C++, justement parcequ'il n'est pas bien normalisé mais aussi parcequ'il est d'une grande complexité au point de vue syntaxique.
J'ai de tres mauvaises experiences avec les EDI autres qu'Emacs. Jusqu'a present ils m'ont fait perdre plus de temps qu'en gagner: je reviens toujours a Emacs.
Citation:
- plus grande facilité de gestion de la mémoire (he oui, fallait bien en venir à ça)
Je suis un partisant du GC bien utilise... C'est disponible en C++ (mais on sort a nouveau de la norme actuelle). Et le GC a des limites. Et quand ca convient pas en Java tu n'as plus le choix.
Citation:
Bon, je t'ai donné mes arguments en faveur de Java, à toi de me donner les tiens en faveur du C++.
J'ai un gros avantage sur toi: je n'ai jamais pretendu que le C++ soit quasiment universellement meilleur que Java. Il me suffit de trouver un cas ou C++ est plus productif que Java pour quelque chose qui ne soit pas fortement dependant des performances.
Pour moi, la programmation est essentiellement l'art d'utiliser et de construire des abstractions.
Pour l'utilisation
Java a un avantage avec sa bibliotheque standard et le GC. Je le concede sans probleme.
C++ a un avantage quand il s'agit d'utiliser des choses existante par ailleurs ayant une interface C, surtout si ces choses continuent a etre maintenue en parallele.
C++ a un avantage avec la surcharge des operateurs qui permet dans certains cas de donner une interface plus naturelle. Sincerement, meme si je ne suis pas contraint par les performance, pour manipuler des matrices je prefere ecrire A = B * C + C que A = B.mult(C).plus(C).
Le RAII est plus confortable a utiliser que des clauses finally.
Globalement, avantage en productivite au C++ car ses avantages sont sur des couts recurrent et l'avantage de Java sur un cout d'initialisation.
Pour la definition,
Java a un systeme de modularisation nettement meilleur que celui du C++; mais je doute qu'il influence beaucoup la productivite.
C++ permet la definition de types ayant une semantique de valeur, ce qui est difficile si pas impossible en Java.
L'heritage multiple permet de combiner les abstractions avec une souplesse que les interface de Java ne permettent pas.
On peut avoir des fonctions libres quand c'est necessaire.
Meme sans parler de la meta-programmation -- que je considere plus comme un gadget qu'autre chose -- les templates offrent une souplesse sans rapport avec ce que permet Java.
L'existance des destructeurs et l'idiome RAII est aussi un avantage pour le C++.
Pour la definition d'abstraction, avantage au C++ egalement.
Total, avantage en general au C++ mais le GC et la bibliotheque standard de Java peuvent dans certains cas faire de Java un meilleur choix.
Citation:
Mais avant ça, j'aimerais parler d'un argument que je juge complètement irrecevable et que tu vas surement m'énoncer parcequ'il revient 99% du temps: l'optimisation de la vitesse, le controle de la mémoire et "les GC c'est pô bien". Oui un programme Java c'est plus lent que du C++, c'est indéniable, oui on ne controle pas la mémoire à l'octet près, mais et alors? Le but d'un programmeur n'est pas de créer des programmes les plus rapides possibles, mais de créer des programmes, point.
Je le redis, avec les ordinateurs actuels l'optimisation à outrance n'est pas nécessaire, si ce n'est dans quelques domaines bien précis.
J'ai bien l'impression que je suis dans un de ces domaines precis. Nous passons globalement pas mal de temps a chercher a ameliorer la rapidite et la consommation memoire de nos programmes (et oui la consommation memoire n'est pas trop importante... sauf quand son importance fait franchir des seuils: rester en 32 bits ou devoir passer en 64 bits est le premier, ne pas swapper est le second; les deux sont importants pour nos clients; j'ai un collegue qui travaille avec les donnees des clients qui se plaint de ne pas avoir de machine avec plus de 32 G de memoire)
Citation:
L'un des seuls arguments que je trouve recevables que j'ai pu apercevoir sur ce forum est la métaprogrammation, mais on peut vraiment pas dire qu'il soit cité souvent.
Citation:
Tu déformes ce que je dis, c'est limite du troll :)
Je reponds dans le style du message auquel je repond :)
Citation:
Chez moi eclipse prend 200 mo, alors je sais vraiment pas comment tu fais pour atteindre les 6 Go.
Je doute qu'eclipse soit capable de lancer different process pour passer outre la limite de 4G par process... Sinon j'ai simplement fait Importer un executable C++, choisi le programme sur lequel je travaille et puis attendu longtemps.
