A voir le post et le sujet (ou plutôt le fil :)), j'ai la forte impression que JolyLoic parlé d'optim que le développeur apporte, pas d'optim amenées par la compilation ;)Citation:
Envoyé par mchk0123
Version imprimable
A voir le post et le sujet (ou plutôt le fil :)), j'ai la forte impression que JolyLoic parlé d'optim que le développeur apporte, pas d'optim amenées par la compilation ;)Citation:
Envoyé par mchk0123
Surement moins d'impact que tu ne le penses sur la différence C/C++.Citation:
Envoyé par rulianf
Tu perd en temps d'appel entre les différents const./dest. mais c'est mineur sur les CPU d'aujourd'hui (bien moins qu'un branch misprediction).
Ce qui est sur c'est que si tu est accroc aux méthodes virtuelles, aux constructeurs de copies et que tu ne pratique jamais le passage d'objets par référence, ... aie aie aie ... Ca peut faire mal. :marteau:
Donc je serais tenté de dire que plus tu utilises un langage abstrait, plus tu à de décisions (correctes) d'implémentation à prendre car tu auras toujours plus de combinatoire pour faire la même chose que si tu utilises un langage plus proche du bit code.
Bon, je crois qu'on a tous compris que le C++ n'est pas lent en lui même et qu'un code C compilé avec un compilo C++ produira exactement le même résultat.
Je vais prendre un petit exemple:
A priori ces deux codes sont similaires, sauf que la fonction at() de vector vérifie systématiquement si la taille de vecteur et renvoie une exception si elle est dépassée. Donc si N=10 000, cela fera 10 000 vérifications inutiles puisque on sait très bien qu'on ne dépassera pas la taille de ce vecteur (oui, les gourous de la stl me diront qu'on peut utiliser l'opérateur [] qui ne fait pas cette vérification ou encore des itérateurs, mais c'est pour illustrer et j'avais pas d'autre exemple en tête :P).Code:
2
3
4
5
6
7
C'est inévitablement plus lent, c'est une des conséquences quand on fait des classes "super-safes, où tout est toujours libéré correctement, où rien ne peut jamais se retrouver dans un état incohérent à quelque instant que ce soit". Pour généraliser on pourrait même énoncer une loi du style: toute abstraction entraine une perte d'optimisation.
Ce n'est pas forcément lié au C++, pour reprendre notre exemple il existe aussi des biblios pour faire des tableaux plus sécurisés en C. Le C++ se distingue juste parceque cela est plus facile, plus naturel.
Je précise ce que j'ai dit :Citation:
Envoyé par mchk0123
Plus un langage à une puissance d'expression etendue (ce qui le cas de C++ par rapport à C, car il ajoute des concepts sans en enlever), plus il y à de combinaisons possible pour implémenter un processus donnant le même résultat.
Du coup on à plus de décisions correctes à prendre ...
... Donc plus de probabilitée d'écrire du code peu optimisé si on y fait pas attention.
Vraiment bizarre ton raisonnement. J'ai beau y réfléchir, je ne peux qu'en arriver à la conclusion inverse. Plus un langage a d'expressivité, moins il faut de lignes pour résoudre un problème. Moins il faut de lignes, moins il y a de combinaisons possibles. Donc moins de décisions à prendre.Citation:
Envoyé par mchk0123
Et qui dit moins de décisions à prendre dit, non pas moins de probabilité d'écrire du code peu optimisé, mais moins de probabilité de faire une erreur, qui fera que le programme ne fonctionne pas.
Je ne vois pas le rapport direct entre ton raisonnement et l'optimisation...
Je ne parles pas de capacité offerte par le langage d'écrire le meilleur code optimisé (auquel cas le C++ est meilleur que le C) mais bien de probabilité pour tomber par hazard sur la meilleur implémentation d'un processus.
Plus un langage à une puissance d'expression élevée, plus cela te permet d'écrire des programmes longs et compliqués.
Donc à connaissance 0 en optimisation, si tu est débutant et que tu écris un programme simple en ASM tu à plus de chance qu'il soit performant.
Maintenant, toujours à connaissance 0 optimisation, si tu est débutant et que tu écris un programme complique en C++ tu à moins de chance qu'il soit performant.
Autrement dit, écrire de manière optimisée en C++ nécessite un degrée de connaissance, attention et expérience supérieur.
Ton exemple sur std::vector et le bound checking était trés bon.
Explication un peu plus clair de ma part :
Pas tout à fait. Pour un même problème à résoudre (par exemple multiplication de 2 matrices), si tu as à un langage à puissance d'expression supérieure, tu aura plus de manières possibles d'écrire la solution. Donc moins de probabilité de ... etc.Citation:
Envoyé par zais_ethael
Ce n'est pas le 0 connaissance en optimisation qu'il faut considérer, c'est le 0 connaissance dans le langage et les bibliothèques offertes.
Quelqu'un qui n'y connait rien en optim, mais qui connait Blitz++ (/boost.ublas / ATLAS / ...) écrira des choses plus performantes que le premier venu en assembleur. Il écrira même des choses plus performantes que quelqu'un qui croit s'y connaitre.
Je ne vois pas ce que prouve cet exemple sur les vecteurs non plus. Qu'il faut lire la documentation des fonctions que l'on utilise ? Cela a d'ailleurs été très bien dit. Les fonctions sécurisés en C ont également un sur-coût.
Ce n'est pas lié au langage! (le sujet du fil). C'est lié au bibliothèques utilisées. Si on ne lit les les doc, si on ne se renseigne pas sur ce qui existe, si on se croit meilleur que les autres et faisons dans le NIH, ... Cela fait plein de "si". Aucun de ceux-ci (de "si") n'est lié au langage. Et tous ces "si" là peuvent avoir des implications négatives sur la maintenabilité, la robustesse et les performances.
Oui le C++ est complexe. Oui il permet d'écrire des choses de plus de façons différentes. Des qui seront plus rapides, des qui seront moins efficaces. C'est comme le perl. Et alors ?
Il y a des risques bien plus importants que les perfs quand on n'apprend pas à ce servir de ces langages. A quoi bon foncer dans un mur?
Raisonnement marketing et commercial. Tu peux donner des exemples de ce que tu avances ?Citation:
Quelqu'un qui n'y connait rien en optim, mais qui connait Blitz++ (/boost.ublas / ATLAS / ...) écrira des choses plus performantes que le premier venu en assembleur. Il écrira même des choses plus performantes que quelqu'un qui croit s'y connaitre.
Que viens faire le perl ici ?Citation:
Oui le C++ est complexe. Oui il permet d'écrire des choses de plus de façons différentes. Des qui seront plus rapides, des qui seront moins efficaces. C'est comme le perl. Et alors ?
Tu peux développer un peu ?...Citation:
Il y a des risques bien plus importants que les perfs quand on n'apprend pas à ce servir de ces langages. A quoi bon foncer dans un mur?
Moi ce que j'essaie de dire, c'est qu'on ne peut pas tout avoir. Un programme qui soit à la fois the plus rapide, the plus stable, the plus facile à maintenir ça n'existe pas.Citation:
Envoyé par Luc Hermitte
La programmation en C++ veut qu'on essaie de s'abstraire le plus possible des taches ingrates, en C on est quand même obligé de s'en farcir pas mal. Mais cette abstraction a un cout, une gestion moins fine de ces taches, ce qui entraine un baisse de performance.
Programme + lent ne veut pas dire programmeur - bon ou biblio - bonne. Tout est question de choix, on peut très bien (et tout le monde le fait) laisser l'optimisation de coté pour privilégier la facilité de programmation et obtenir un gain de productivité, sinon tout le monde ferait de l'assembleur.
C'est aussi pour ca que Java et C# existe et que tout le monde quitte le C++
Voila :) Mais bon on aura quand même toujours besoin de langages permettant un programmation très optimisée (programmation système, moteurs 3D, ect...)
Les abstractions de C++ n'ont pas de coût particulier.
Et ce n'est pas en écrivant en assembleur que tu produiras du code optimisé. Le compilateur et les optimiseurs sont bien meilleurs pour générer de l'assembleur.
Tu viens de montrer que tu n'as aucune connaissance d'optimisation en assembleur. Sur une machine moderne, il n'y a aucune chance qu'un code naïf soit performant. Et moderne de ce point de vue, ça commence au Pentium I.Citation:
Envoyé par mchk0123
Si mais pour la compréhension des autres lecteurs tu peux développer un peu ? Et surtout, pour rebondir sur le sujet du post, est-ce que les compilateurs C et C++ savent bien tirer profit de toute la complexitée des CPUs modernes et de la gamme assez variée.Citation:
Envoyé par Jean-Marc.Bourguet
Dans ce cas, pourquoi fais-tu une affirmation qui n'a probablement été vraie -- si elle l'a été -- qu'au tout début des langages compilés (qu'un débutant en assembleur a plus de chance de produire un programme performant qu'un débutant dans un langage compilé).Citation:
Envoyé par mchk0123
Les processeurs modernes tirent leur puissance de leur capacité à exploiter le parallélisme qu'il est possible d'extraire du flux d'instructions. Une partie du travail d'optimisation consiste à rendre le plus possible ce parallélisme visible.Citation:
mais pour la compréhension des autres lecteurs tu peux développer un peu?
Pour répondre à ta question, s'il y a une tâche que les ordinateurs font mieux que les hommes, c'est bien gérer des détails de ce genre -- surtout plusieurs fois après modification du programme ou pour des architectures ou des micro-architectures différentes. Depuis longtemps, pour battre un compilateur optimiseur, la technique n'est pas de chercher à faire mieux là-dessus -- ce qui est parfois possible sur des cas plus ou moins particulier -- mais, d'une part, de chercher à profiter de propriétés qui ne sont pas ou difficilement accessibles aux compilateurs (des propriétés globales) et d'autre part de ne pas respecter des contraintes que les compilateurs respectent (passer par registre quand l'ABI qui exige un passage sur la pile est un grand classique)Citation:
Et surtout, pour rebondir sur le sujet du post, est-ce que les compilateurs C et C++ savent bien tirer profit de toute la complexitée des CPUs modernes et de la gamme assez variée.
Pour revenir réellement au sujet, il n'y a aucune raisons pour qu'un compilateur C soit sur ce point plus performant qu'un compilateur C++.
J'admire le tout le monde...Citation:
Envoyé par epsilon68
ah oui, mais la non!!!
En ce moment, je m'efforce d'apprendre le C++. Alors si tout le monde passe en java ou C#, ca sert a rien d'apprendre le C++.
La question que je me pose n'est pas la rapidité du C++, mais est ce que le C++ a encore de l'avenir ?
c'etait bien sûr un peu ironique ...Citation:
Envoyé par Jean-Marc.Bourguet
et ce que je vois des arguments du C++ vs C, ce sont les memes que du Java vs C++
en lisant les posts, je me dis que Java optimise a la volée son code suivant le materiel alors que le C++ non... donc Java finira donc par etre plus rapide
mais bon je m'egare
le debat du C++ vs C n'a aucune raison d'etre, ni comment l'objet peut etre mis en cause pour des raisons de performance. Il vaut mieux regarder Qt et GTK, il est clair que Qt progresse plus vite et a une API 10000 fois plus limpide...
C++ l'optimise avant l'execution. Le seul avantage de Java dans ce cas c'est qu'on a pas besoin de recompiler (en théorie) pour passer d'une plateforme a l'autreCitation:
Envoyé par epsilon68
a- C'est mal me connaitre :lol: C'est un raisonnement de fainéant qui n'aime pas réinventer la roue.Citation:
Envoyé par mchk0123
b- Hum .. Connais-tu les bibliothèques que j'ai citée ? Ce sont des bibliothèques robustes de calcul matriciel hautes performances en C++ et C (pour ATLAS).
Tu trouveras des benchmarks sur les divers sites ; quand on a atteint les perfs des BLAS, je pense que ça va. Et oui, je t'assure que le petit débutant qui n'y connait que dalle en optimisation en assembleur ne saura pas être aussi performant que le petit débutant qui n'y connait que dalle en optimisations en C ou C++, mais qui utilise des bibliothèques dédiées qui sont elles optimisées. Je pourrais parler de pipeline, de flôts d'exécution, etc., je ne ferai que rejoindre ce que Jean-marc a dit.
Après, il y vraiment des gens qui croient s'y connaitre mieux que les autres (j'en croise de temps à autre), qui veulent tout reprendre sur un ouïe-dire vieux de 10 ans, pour au final développer des trucs instables et inutilisables, quand ils ne sont pas plus lents. Parfois ils ne connaissent juste pas le C++ et réinventent la SL.
Comme le C++ il y a 150 façons différentes de faire quelque chose en perl. Est-ce que pour cela on parle que statistiquement il y a plus de chances d'être lent parce que des gens ne connaitront pas la façon la plus optimale ?Citation:
Que viens faire le perl ici ?
OK. Il est juste facile de se tirer dans le pied en C, (et quand on y arrive en C++, c'est toute la jambe qui part. Vous connaissez le "dicton"). Et en C++, être robuste et maintenable demande un minimum d'initiation.Citation:
Tu peux développer un peu ?...Citation:
Il y a des risques bien plus importants que les perfs quand on n'apprend pas à ce servir de ces langages. A quoi bon foncer dans un mur?
Ce que je dis n'a rien de marketeux. Ce n'est que mon expérience.
C'est un tout autre débat qui a son fil à lui. Je t'invite plutôt à y reposer ta question si tu penses que ce qui y a déjà été dit n'y répond pas.Citation:
Envoyé par deubelte
Accessoirement, si tu connais le C++, tu ne devrais avoir aucun mal avec les deux autres. Tu risques de te sertir bridé (c'est mon cas) si tu t'habitues trop aux templates, à la sémantique de valeur, au RAII, ... Ils restent des langages différents.
Parenthèse: ta question me fais penser à ce que j'avais lu sur le blog de Joel Spolsky (ortho?) (de joelonsoftware) qui regrette que les java schools soient aussi répandues, ce qui impliquerait un manque de culture et de familiarité avec le cambouï.
Sauf que le débat peut aussi traiter de fonctionalités dont est dépourvu le Java. Alors que le C++ reprend énormément de choses du C. Et que C comme Java ont peut-être des ABIS (ou assimilé) mieux définies que le C++.Citation:
Envoyé par epsilon
Bref. Certes dans un cadre donné, mais on ne peut pas dire "cela reprend presque tout", ce qui fait que le débat n'est pas vraiment le même.
Salut,
Il te suffit de regarder les option de compilation fournies par ton compilateur pour t'en convaincre:Citation:
Envoyé par mchk0123
Que ce soit gcc, g++, ou les compilos de chez microsoft, tu peux choisir, sur PC, l'architecture processeur à pour laquelle tu souhtaites qu'il optimise l'exécutable parmis la liste des architectures qui existaient au moment où le compilo est devenu accessible.
Cela implique qu'il te faille alors choisir entre un code optimisé pour une architecture plus ancienne, mais donc susceptible de tourner sur plus de machine ou un code pour "la dernière architecture" mais donc plus restrictif au niveau des machines sur lesquelles il sera en mesure de tourner...
Ca c'est un autre débat, qui a d'ailleurs déjà cours sur le forum, mais, bien sur que le C++ (tout comme tous les autres langages) ont de l'avenir...Citation:
Envoyé par deubelte
Surtout si tu compares un(des) langage(s) compilé à un(des) langages interprétés/nécessitant une machine virtuelle pour fonctionner.
L'une des raisons "facile" est qu'il faudra des langages "compilés" pour permettre la création de systèmes d'exploitation sur lesquels faire tourner les interpréteurs/machines virtuelles ;) mais de nombreuses autres raisons font que tous les langages ont malgré tout de l'avenir (y compris les plus anciens que tu pourras trouver ;))
Pour en revenir au débat... et en se limitant à la comparaison C->C++, j'ai tendance à estimer que, bien plus que le langage en lui-même, trois grands critères ayant trait au programmeur sont de nature à influencer la rapidité d'exécution de l'application:
- le niveau de tolérence/ gestion/récupération d'erreur souhaité:
Il n'est pas rare que, pour effectuer la gestion d'erreurs, et éventuellement les récupérer, on obtienne un code trois à quatre fois plus important, et au final *vraissemblablement* plus lent à l'exécution, que le code qui serait créé sans prendre cette gestion d'erreur en compte...- l'algorithme utilisé:
S'il n'est pas adapté, ou pas optimisé, il y a vraiment peu de chances que l'application résultante soit rapide ;):P- la connaissance et l'utilisation à bon escient des bibiothèques ad-hoc mises à disposition
une bibliothèque maltraitée par de nombreuses personnes sera *vraissemblablement* bien plus optimisée que le code fournis par quelqu'un qui essayerait de "réinventer la roue"
La connaissance d'une telle bibliotheque et son utilisation à bon escient sera au final *vraissemblablement* bien plus rapide et/ou sécurisante que le meme code "fait main" par quelqu'un qui pourrait sans doutes n'en avoir pas appréhendé l'ensemble des tenant et des aboutissants ;)
Si l'on voulait étendre le débat aux autres langages de programmation, la seule chose qui changerait est le fait que certains langages ont été créés pour des situations ou une utilisation précise, ou des domaines particuliers et que, de fait, ils auront des chances d'être plus rapides dans leur domaine particulier que d'autres potentiellement plus "généraux"...
Ça, c'est une simple différence entre compilation normale et compilation JIT.Citation:
en lisant les posts, je me dis que Java optimise a la volée son code suivant le materiel alors que le C++ non... donc Java finira donc par etre plus rapide
Que ce soit pour Java ou pour C++, les deux sont possibles.
Il est d'ailleurs intéresser de mélanger les deux.
Mac OS X le fait pour accélerer son système de rendu basé sur OpenGL qui a une part de dynamisme (détection et chargement des extensions je pense)
ok j'etais de mauvaise foi de toute facon :aie:Citation:
Envoyé par loufoque
d'apres mes propres benchmarks le java (28sec) est significativement plus lent que C++ (8sec)
je prefere le C++ que ce soit clair, mais Java est une bonne alternative comme language simple et "assez" rapide dans la plupart des cas.
J'avais notamment le cas au boulot d'un environnement de production super restreint, ou seul Java pouvait etre utilisé. Au final juste quelque jars et hop le tour etait joué.
Je n'utilise pas C++ au boulot, C# et Java sont les uniques axes de development (IT). Je pense meme que C++ est mort sur Windows avec leur tout .NET Serieusement ca m'inquiete un peu sur l'avenir de C++....
L'enterrement est prévu pour quand ?Citation:
Envoyé par epsilon68
Pas de soucis de ce côté là, Studio permet encore de compiler du code C++ normalisé non CLI. Et puis il reste encore de bon compilo. gratuits.Citation:
Envoyé par epsilon68
... meme pire si je faisais une offre avec C++ dessus je serais eliminé au premier tour, il n'y aurait personne capable de le maintenir, et puis C++ ca fait peur a tout le monde point de vue temps de development, maintenabilité ....
moi j'y peux rien, ce sont les clients et nos managers les premiers decideurs....
C++ n'est pas a la mode malheureusement ... du moins dans mon secteur ...
... alors C ... encore moins
Mais là, tu tires une généralité tout à fait fausse du cas particulier qui est le tien...Citation:
Envoyé par epsilon68
Si je ne connais pass assez ton secteur pour te contredir dans ton secteur particulier, il est aberrant de généraliser le fait que "personne" ne serait capable de maintenir du C++ ou que le C++ fait peur à tout le monde...
Quelque soit le langage envisagé, tu trouveras des gens qui auront peur de s'y frotter, et d'autres qui ne jureront que par lui...
je serais heureux d'avoir tort, et j'ai toujours dit en fonction de mon domaine d'activité.
En meme temps dure d'etre general, il y a tellement de domaine...
vous etes dans quel domaine ?
ca pourrait etre intéressant de partager les experiences dans les differents domaines non ?
personne ne veut parler de son domaine et m'aider a voir de facon plus generale ?
Si je te dis que mon domaine, c'est l'EDA (Electronic Design Automation, la CAO en électronique). Ca t'avance à quoi?Citation:
Envoyé par epsilon68
Je crois que le mythe à tuer, c'est le langage universel qui rempli tous les besoins. Je suis sûr que Java rempli certains besoins mieux que le C++; ce n'est simplement pas les nôtres.
Je me dis que c'est cool ...Citation:
Envoyé par Jean-Marc.Bourguet
moi je faisais de la 3d CAM avant mon emploi actuel, et je me suis fait un engine en Java pour voir la reelle difference... et il y en a une alors pour mes trucs persos je suis en C++
tu ne me convaincras pas sur le language universelle qui n'existe pas ... non je suis déjà persuadé, mais bon je me demandais sur vos opinions / experiences...
tu fais un programme portable ? tu utilises quoi comme libs etc ?
Nous écrivons du code relativement standard (càd que nous ne nous en éloignons pas trop volontairement), mais je doute que l'ensemble puisse être porté facilement sur autre chose qu'un Unix.Citation:
Envoyé par epsilon68
Rien qui ne soit pas du développement interne. L'interface est fait en QT -- ou avec une couche au dessus -- mais je n'y touche pas.Citation:
tu utilises quoi comme libs etc ?
Merci c'est cool
De mon point de vue C et C++ sont deux frêres.
Ce qui fait une petite partie de la différence est le style de code et comment il est ensuite compilé.
Le C++ apporte les classes et templates, une classe n'est simplement qu'une structure composé d'un pointeur vers le tableau des pointeurs sur ses méthodes, et des ses attributs ... à partir de là il s'agit d'une légère différence de taille (le tableau est statique). Les templates sont généré en différente fonctions ... ces fonctions seront selon le compilateur compilée exactement de la même façon qu'en C (quel est le fou qui code 25 fois la même fonction pour des types différents ?).
Donc au final la rapidité ne se jouent pas sur l'assembleur généré puisque les instructions C++ sont en C ... le C++ permet principalement de réduire la taille du code pour des problèmes spécifiques (multi type, necessité d'utiliser des objets etc..).
LA GRANDE PARTIE de la différence de rapidité viens du fait qu'une classe C++ est sensée ne pas être destinée à infliger de contraintes d'arguments, le but de la POO est de réutiliser le code sans à chaque fois redefinir les predicats. J'en viens donc au fait que la rapidité dépend du nombre de verifications sur arguments ... en C++ on en vient même a wrapper les classes dans des smart_pointer pour éviter les boulettes ... une verification du plus ... et encore une ... ce qui rapproche la rapidité de ce code C++ à celle du java où tout est vérifié puisque les objets servent à tout et n'importe quoi.
D'après moi, la meilleure façon de conserver l'équilibre est de connaitre son code, et connaitre le fonctionnement de ses dépendances (lire la classe vector ne fait pas de mal) d'une part. D'autre part d'éviter les vérifications inutiles (miser sur l'intelligence du réutilisateur ne vous fait rien perdre, no pity for dummies). Le C PEUT servir en C++, arretons un peu la bataille, un char* à la place d'une string c'est pas la mort à gérer vous même et au moins on sait ce qu'il se passe (mais recodez strlen, vive le buffer overflow).
La règle d'or : on est jamais mieux servi que par soi-même ! Donc les libs ne les choisissez pas si c'est pour 10 fonctions ...
[j'utilise boost, avec parcimonie bien entendu ^^]
Un petit résumé :
C/C++ c'est pareil au niveau compilation ... les mêmes instructions compileront de la même manière ... La différence vient du style de programmation. Ce style de programmation est choisi en fonction des besoins et performances cibles.
la performance se base sur : la vitesse, la portabilité, la mémoire requise.
Et ces trois choses, on une importance différente suivant le besoin.
Jeux utilisant des entités -> objets -> C++ (en style C quasiment impossible à réaliser proprement)
Jeux 3D -> les ressources 3D sont des objets, le C++ est plus convenable
Jeux 2D -> C ou Java, le C sera plus rapide mais plus long à coder.
Appli de calcul -> asm, C ou C++ suivant le problème
Appli de gestion commerciale -> Java parce que très utilisé, à la mode, et que ma soeur (non existante) de 6 ans arriverait à cliquer sur les corrections d'erreur d'Eclipse. Et la rapidité dans ce cas n'est pas demandé, plus l'appli met de temps, plus le commercial est libre de penser à comment il va dépenser sa fortune le week-end.
Appli type gestion boursière : C / Caml / Prolog, des languages qui tiennent la route, le prolog est sans faille.
+1Citation:
Envoyé par ThiSpawn
Le C++ t'apporte l'objet. L'objet t'apporte la possibilité (mais pas la certitude) de coder fiable, robuste, maintenable et lisible y compris dans des projets complexes et volumineux.Citation:
Envoyé par ThiSpawn
La taille des projets en C est limitée à ce que le cerveau du moins "mémoriel" (quel est le bon terme ?) de l'équipe peut contenir comme information.
C'est pour éviter cela qu'on a inventé l'objet. Pour que 40 personnes puissent travailler chacun sur le même code en étant d'accord simplement sur l'interface (et donc sans avoir à lire le code des autres).Citation:
Envoyé par ThiSpawn
Même remarque.Citation:
Envoyé par ThiSpawn
Derniers éléments en vrac :
1. il existe des jeux 3D,en Java ,sur la marché, et qui font un carton Java utilise ici un autre atout qu'est la portabilité.
2. on peut coder "bien" (au sens fanatique du terme) en Java, mais c'est dur. Beaucoup plus dur (selon moi) que de coder "bien" en C++, parce qu'il faut comprendre comment fonctionne la JVM.
3. L'actualité nous montre que Java "marche" là où aucun autre langage n'a jamais réussi à fonctionner. Et il marche non-pas parce qu'il est rigoureux, non-pas parcequ'il est performant, non-pas parce qu'il est efficace, mais parce qu'il est facile à utiliser. Autrement dit : c'est plus facile de lever une armée de codeurs Java que de lever une armée de codeurs C++. De plus, l'armée de codeurs Java obtient des résultats (même moins bons) plus rapidement, et donc pour un résultat assez long à obtenir, seul Java permet une solution. Un exemple ici de quelque chose qu'on a longtemps essayé de faire, mais qu'on a jamais réussi en C et C++.