Discussion :

[Luc Hermitte]

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.

a- Raisonnement marketing et commercial.
b- Tu peux donner des exemples de ce que tu avances ?

a- C'est mal me connaitre C'est un raisonnement de fainéant qui n'aime pas réinventer la roue.
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.

Que viens faire le perl ici ?

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 ?

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?

Tu peux développer un peu ?...

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.

Ce que je dis n'a rien de marketeux. Ce n'est que mon expérience.

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'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.
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ï.

et ce que je vois des arguments du C++ vs C, ce sont les memes que du Java vs C++

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++.
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.

[koala01]

Salut,

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.

Il te suffit de regarder les option de compilation fournies par ton compilateur pour t'en convaincre:

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...

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 ?

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...

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
• 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"...

[loufoque]

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

Ça, c'est une simple différence entre compilation normale et compilation JIT.
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)

[epsilon68]

Ça, c'est une simple différence entre compilation normale et compilation JIT.
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 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
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++....

[mchk0123]

C++ est mort

L'enterrement est prévu pour quand ?

Je pense meme que C++ est mort sur Windows avec leur tout .NET Serieusement ca m'inquiete un peu sur l'avenir de C++....

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.

[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

[koala01]

... 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...

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...

[epsilon68]

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...

[epsilon68]

vous etes dans quel domaine ?

[epsilon68]

ca pourrait etre intéressant de partager les experiences dans les differents domaines non ?

[epsilon68]

personne ne veut parler de son domaine et m'aider a voir de facon plus generale ?

[Jean-Marc.Bourguet]

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?

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.

[epsilon68]

Si je te dis que mon domaine, c'est l'EDA (Electronic Design Automation, la CAO en électronique). Ca t'avance à quoi?

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 ...
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 ?

[Jean-Marc.Bourguet]

tu fais un programme portable ?

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.

tu utilises quoi comme libs etc ?

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.

[epsilon68]

Merci c'est cool

[ThiSpawn]

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.

[Feriaman]

De mon point de vue C et C++ sont deux frêres.
...
Donc au final la rapidité ne se jouent pas sur l'assembleur généré puisque les instructions C++ sont en C ...

+1

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..).

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.
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.

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.

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).

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 ....

Même remarque.

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++.