Hi,
 
 
Je lis beaucoup d'avis négatif (venant d'informaticien expérimenté) sur le C++, lourd,rigide, langage bidouiller dû à son héritage du C etc..
Aussi je me demandais quel est l'avenir réel de ce langage....
Peut on considérer ce langage comme en dessous des langages actuelles/futurs, ou est ce que selon vous le C++ restera  un langage phare dans l'avenir ?
 
Ty

Avis aux futurs répondants : ce genre de topic étant propice aux trolls en tout genre, le premier qui pourrit se prendra une semaine de télétubbies.
Merci de votre attention

Des experts auto-proclamés disent le contraire.

 
Je ne connais pas de langages de programmation ne meritant pas de critiques.
 

 
Il y a une trop grosse base installee pour raisonnablement penser que le langage n'a pas d'avenir.  Il y a trop de developpement en cours pour penser que son avenir est restreint a la maintenance (ce que n'est pas le Cobol).  Il y a trop d'applications de type differents dans des milieux differents pour penser que son avenir est d'etre un langage de niches (ce que le C est peut-etre en train de devenir, mais ses niches sont quand meme grandes dans ce cas).
 

 
C'est quoi ta definition de langage phare?

Moi j'ai des sources experimentés qui disent la même chose de JAVA, C#, FORTRAN, etc...
 
C++ est là, il est vivant ( une nouvelle norme ets prévue pour bientot)
 
Un langage c'ets avant tout ce que l'on en fait. Mauvais programmeur en C++ = mauvais progamme en C++.  
 
Un langage c'ets un outil, faut juste savoir quel outil est adapté à telle tache. Moi, je vois pas de rempalcant à C++ dans la niche "langage multi-paradigme compilé"
 

 
 
J'entends par là un langage qui restera sur le devant de la scène, qui restera très utilisé en entreprise dans diverses projets, et pas seulement dans des projets de folie genre fusée ariane. Un langage qui ne se fera pas bouffer par C#/Java etc  

Un langage informatique est un outil. Pas plus, pas moins.
C# et Java sont de bons langages, mais qui n'occupent pas la même niche que C++, qui lui-même n'occupe pas la même niche que Fortran, ou Haskell, ou Ruby, ou PERL, ou BrainFuck Prolog.

Bref. C'est un outil. Qui ne sera mort que lorsque personne ne l'utilisera plus.
Ça arrivera probablement (comme pour tout langage), mais ce n'est pas d'actualité aujourd'hui.

 
C++ ne sera plus jamais le dernier langage à la mode qui a du buzz autour de lui.  Il survivra probablement à quelques uns des prochains langages à la mode.
 

 
J'ai pas l'impression qu'il n'est pas utilisé en entreprise.
 

 
Je suis peut-être sur des projets "genre fusée ariane" pour toi (gros machins existant parfois depuis plus de 20 ans avec des dizaines de développeurs, et dont la license pour certaines options a un prix officiel à 6 chiffres) mais ici le C++ est loin de se faire bouffer par C# (la plupart de nos produits ne sont même pas sous Windows) ni par Java (les sous-projets qui l'ont tenté sont en cours de réécriture ou ont déjà été réécrit en C++).  Il est probable qu'il va avoir plus de présence sur des projets lourds et contraints que pour afficher trois champs extraits d'une DB après une requêtre SQL.

ok merci on verra bien ce que nous réserve l'avenir, mais ça me semble  objectif comme avis

Le C++ comme dit précédemment possède une "particularité" qui a tendance à se perdre mais qui en fait également un grand avantage. Il s'agit d'un langage compilé entièrement. Ce n'est pas le cas de Java ou de C# (.net en général) qui utilise une machine virtuelle.
 
Compilé certes mais très facilement portable grâce à la grande qualité de ses compilateurs (GCC pour ne citer que lui)
 
Cela donne au C++ un net avantage sur les environnements peu puissant ou nécessitant une grande vitesse de calcul. Je pense par exemple aux environnements embarqués, à la création de systèmes d'exploitations, etc...
 
La tendance aujourd'hui est à la machine virtuelle et à l'utilisation de nos ordinateurs en tant que terminaux légers.
Nous verrons ce que l'avenir nous dira mais je pense que le C++ a encore de beaux jours devant lui.

L'argument de la dispersion, c'est quand même assez foireux. Autant je vois une ligne directrice dans C++, autant par exemple C#1 était assez propre et carré, mais 3 versions plus tard, c'est devenu un sinistre merdier.

 
HPC et tout ce qui demande des performances élevées en général

C'est un mauvais à priori et une réputation qui commence à dater que de dire que Java est plus lent que C++. Cela fait bien 5 ans que les deux langages sont à peu près équivalents si l'on omet le bootstrap de la VM.  
 
http://www.idiom.com/~zilla/Comput [...] hmark.html

faut voir la tete des benchs aussi. Je pleure aussi sur la quantité de FUD dans ce lien ...
J'estime personnelement que dire "oui VEctor est lent utilisé ArrayList ca va plus vite" est un echec du langage.

Y a un troll de 2474587km sur developpez.com sur le meme sujet. C'est assez stérile.

Si Java est si rapide et si cool et si portable, je me demande pourquoi on ne code pas plus de jeux vidéo avec ce langage dans l'industrie? O_o
 
Je veux pas faire le mauvais troll, mais c'est complètement absurde de dire qu'on peut faire tout ce qu'on fait avec du C++ avec Java et que ce ne sont que des habitudes de vieux programmeurs...
D'ailleurs si Java était si performant ça ferait longtemps que les développeurs seraient passés dessus pour les applications critiques, seulement ça n'est pas le cas...
 
Essayez un peu de faire tourner la VM java sur les SPU d'un Cell par exemple, et on va bien rigoler.

Peut-être parce que Java n'est pas au top dans le multi-thread, qu'une machine virtuelle occupe une quantité non-négligeable de mémoire dans le cadre d'un jeu, que le fait d'être "coupé" (partiellement) de l'environnement n'est pas souhaité et rend l'optimisation spécifique (os, drivers, matériel) difficile ou qu'encore parce que la majorité des moteurs graphiques, physiques et bibliothèques diverses sont écrites en C ou en C++.

 
Ca me semble justement être un argument en faveur de C++
 
Edit : Au final, ce qui me semble primordial dans C++, c'est cette proximité du matériel. C'est d'ailleurs pour pouvoir mélanger différents niveaux d'abstraction que le langage a été fait.

Exactement. C'est, je pense, une partie des motivations ou des raisons qui font que Java n'est pas utilisé dans le domaine du jeu-vidéo ou moins utilisé que le C++. Ca ne fait pas de Java un langage plus lent, moins portable, moins agréable.  
 
Je pense qu'il est aisé de comprendre que les choix du marché ne sont pas systématiquement les meilleurs choix, mais qu'ils sont là ! Sans vouloir lancer un troll bien poilu, mais parce que la comparaison est suffisamment caricaturale pour illustrer mes propos, c'est comme constater que Windows est largement plus répandu alors que GNU/Linux est meilleur qualitativement parlant. (svp, pas de troll, ce propos n'a pas valeur de vérité, mais permet d'illustrer ce que je veux dire).

Je suis d'accord sur le fond, c'est pas parce que quelque chose est répandu qu'il est bien (Titanic c'est tout pourri!), mais dans les fait, pour notre "problème", c'est bien le cas à mon avis.
Même si dans la théorie, on peut faire tourner Java sur une PS3, dans la pratique, on n'aura JAMAIS les performances identiques (et de très loin).
 
J'ai déja vu des bench disant que Python > C++ dans certains cas, et pourtant par expérience, après avoir fait tourner Python sur une PSP, je peux te dire que ça tourne 100 fois moins bien dans la pratique.

C'est une blague?

Non parce que même si c'est de la boue, java est quand même largement supérieur au C++ niveau gestion de la parallélisation (et sauf utilisation de libs spécifique limitées à des contextes précis genre OpenMP c'est généralisable) L'industrie des JV commence à peine à se lancer dans le multithreading/multiprocessing (contrainte et forcée) et pour le moment c'est surtout la catastrophe à ce niveau Cf "The Next Mainstream Programming Language" par Sweeney qui parle de ça pendant 12 slides (sur 67)

En perfs? Je pense pas non, ou alors sur des nano-benchmarks sans aucun intérêt.

Non, ce n'est pas une blague. La surcharge induite par la gestion du multi-thread de Java ne le rend pas du tout efficace par rapport à ce que l'on peut faire (en restant prudent) en C/C++, la question n'étant pas de savoir si, à efforts égaux, les langages se valaient.

Quelle surcharge?

punaise y a bien un truc ou je donnerais mon bras droit , c'est bien pour avoir le support des threads de JAVA en C++.
 
Ce probleme sera le feature qui decidera de la vie ou de la mort de pas mal de chose dnas les 5 ans à venir.

 
Effectivement, c'était des benchs complètement spécifiques et pas du tout pertinents, mais ca rejoins effectivement ce que je dis. Jusqu'à ce que je vois des bench pertinent ou des exemples en pratique montrant que ces langages sont capables de performances équivalentes à un même programme écrit en C++ je continuerai à me baser que sur mon experience pour dire que effectivement le C++ sera plus performant.
 

Je ferais pas ça à ta place, il est indéniablement meilleur que celui du C++ (qui n'en a fondamentalement aucun), mais ça reste pas impressionnant du tout.

un truc middle > un rien quand même
 
meme les futures en C++0x c'ets pas bandant car y a pas de notion de rendez-vous

C'est pas un truc middle la concurrence en java, c'est un truc mauvais

Bon ok c'est mieux que rien du tout, mais ça vaut pas un bras, un ongle, jusqu'à une phalange à la limite mais pas plus

 
Je pense pas que que ce soit de la boue -- mais je connais mal.  En fait je considere que je ne connais pas assez Java pour commenter reellement sur les details.
 
L'idee d'un Saint Graal des langages qui serait le meilleur choix dans tous les contextes me semblent une absurdite.  Et dans les gueguerres de comparaisons de langages il y a un extraordinaire melange de mauvaise foi, d'incompetance, de meconnaissance, de refus de considerer comme normal qu'on puisse faire un choix d'un autre compromis entre tous les criteres qui interviennent dans la conception, le refus de considerer comme viable les contournements qui sont utilises en pratique tous les jours, qui noient les quelques critiques fondees.
 

 
Si tu exclus les lib et les normes externes, comme il n'y a rien en C++03, c'est sur.  (D'un point de vue historique, Java a apporte deux choses dans le mainstream: les GC et les grosses libs standards -- C++ n'est certainement pas dans cette tendance).
 
Mais a ma connaissance, Java a en ce qui concerne la parallelisation le meme probleme qu'ils avaient en ce qui concernait le calcul en FP: c'est surspecifie en pratique et le respect de cette surspecification a un cout (voir les papiers du comite C++ consacre au modele memoire pour C++0X).  Cette surspecification a des avantages (en terme de securite, en terme de debuggabilite,...); reste a voir si les avantages contrebalancent les inconveniants (le retour en arriere de Java sur les FP montre que dans ce cas, la perception au moins etait que non).  Et c'est bien d'avoir des langages qui ont des opinions differentes sur les compromis a avoir en la matiere.
 
En passant, a mon avis, le parallelisme est la derniere chance pour les langages fonctionnels et a etat immuable de passer reellement dans le mainstream.  Je me demande s'ils vont la prendre ou si on va quand meme partir sur un modele plus base sur les etats mutables -- l'OO est de ce point de vue l'evolution naturelle de l'imperatif.  Ca semble partit sur cette voie et je ne suis pas sur d'apprecier tant que ca.

 
Il y a encore eu des changements a Summit la semaine derniere.  J'ai pas eu le temps de regarder pour voir dans
quelle direction.

vous voulez dire que les mecs vont mettre la gestion des threads dans la stl, mais vont pas le faire d'une manière optimale ??? ça me paraît fou

c'es tellement trivial que ca se fait sans reflexion ni problemes  ...

bah oui mais bon c'est quand même leur jobs, c'est sensé être des professionels, si eux ne peuvent pas le faire, personne ne peut le faire, et dans ce cas  les critiques sont infondées

 
Pour quels criteres?  Et qui fait le boulot?
 
On va se retrouver avec un compromis entre les criteres des differents participants, leur force de persuasion et le temps qu'ils sont prets a consacrer a la chose.
 
Et oui, il y a aussi des facteurs non techniques qui vont entrer en cause.
 

 
Ca me parait completement normal.

sauf que non. Y a une tension très forte entre ce que la norme doit proposer, les consensus entre utilisateurs, industriels et puriste du langage et les capacités des compilateurs. ET dire " aller mourir, la norme sera C++2052 car on n'est pas parfait" c'ets chié sur la tete de trop de gens.
 
Mais bon, en JAVA y a pas ces problèmes évidemment

 
Leur job?  Pas sur.  Je doute qu'il y ait une seule personne dont la sortie d'une norme parfaite soit un l'objectif professionnel important.  Et ceux pour lesquels la participation au processus de normalisation est un objectif officiel se retrouvent vraisemblablement avec des conflits d'interets car se sont des employes de fournisseurs de compilateurs et de bibliotheques (ils sont les representants de leur employeur apres tout).  Parmi les simples utilisateurs, leur participation doit etre plutot plus ou moins toleree tant que ca n'interfere pas avec le vrai boulot.
 
A contraster avec les deux premieres normes d'Ada -- la derniere s'est faite plutot sur le meme modele que le C++ -- ou une entreprise etait payee pour concevoir le langage (ou le faire evoluer) avec des objectifs precis.  Dans Ada 83 et Ada 95, il y a chaque fois eu une personne ayant un droit de veto, et tous deux l'ont utilise. C'est pas democratique mais ca confere au langage une plus forte unite.
 

hum effectivment j'avais un peu homis ce genre de contraintes...donc au final on devra toujours recourir à de bonnes libs externes pour avoir ce genre de fonctionalités

longue vie à boost en d'autre terme...

 
boost est au depart issu du comite et toujours bien represente et influent.

boost rempli un role tout à fait honnete et avec succés. C++ sans boost serait par contre dans un bien pietre etat

et pourquoi ne pas intégrer boost dans la stl, dans sa totalité ?