Discussion :

[Arsene Newman]

Pourquoi le langage C++ demeure incontournable 35 ans après sa sortie ?
Son créateur Bjarne Stroustrup revient sur les atouts du langage

Créé il y a 35 ans de cela, le langage C++ demeure toujours un langage incontournable au sein de la communauté des développeurs et cela pour plusieurs raisons selon son créateur Bjarne Stroustrup.

Tout d’abord, Stroustrup tient à positionner son langage au sein de la panoplie de langages existants aujourd’hui, ainsi il explique que le C++ n’est peut-être pas le langage le plus adapté pour créer les applications modernes, mais « aucun langage ne peut exécuter des codes complexes aussi vite que le C++. De ce fait, si l’on prête attention à l’embarqué, au domaine du traitement d’image, aux télécommunications ou encore aux applications financières, le C++ règne en maître ».

L’informaticien danois revient aussi sur les langages qui connaissent une forte popularité en ce moment, à l’instar du langage Go de Google. Il note que ce dernier offre des solutions très élégantes dans certains cas, mais pour lui « Les langages qui se focalisent sur l’élégance des solutions perdent en contrepartie en terme de performance et de généralité, toutefois cela n’empêche pas de prêter attention à ces langages ».

Il rappelle entre autres que son langage est bien loin de la facilité d’utilisation des langages de scripts utilisés actuellement, cela est dû à une raison bien simple : « Le C++ est conçu pour les applications lourdes, il ne se focalise pas sur la facilité d’utilisation, par contre il a toujours été utilisé conjointement avec un langage de script », comme à l’époque de son développement où Stroustrup recourait à des scripts Unix Shell.

De ce fait, le « C++ est pour la haute performance, la haute fiabilité, le faible encombrement, la faible consommation d’énergie et pour toutes ces bonnes choses, non pas pour les amateurs et les applications rapides, car cela ne relève pas de son domaine ».

Enfin, pour le créateur du C++, son langage doit affronter aujourd’hui deux challenges majeurs : « soutenir les développeurs qui sont en charge des tâches les plus exigeantes en matière de performance, de passage à l’échelle et de fiabilité, mais aussi permettre aux développeurs d’être plus productifs en écrivant des codes plus faciles à maintenir ». Tout cela se traduit par les publications de nouvelles versions du langage, comme le C++ 11 et le C++ 14 qui doivent répondre à ces challenges en supportant une plus grande diversité matérielle et en introduisant de nouvelles fonctionnalités.

Source : Interview de Bjarne Stroustrup

Et vous ?
Qu’en pensez-vous ?

[Markand]

Je fais du C++ depuis plus de 2 ans et exclusivement du C++ moderne. Je trouve que c'est un langage assez polyvalent on peut faire du très bas niveau comme du haut niveau. Je pense qu'il peut être adapté à toute les situations du moment que les bibliothèques sont fournies.

Par exemple, pour le développement d'application web, en python et ruby vous avez une panoplie de framework, en C++ il y en a très peu, seul Wt semble réellement maintenu.

Longue vie au C++

[Shuty]

Longue vie au C++

Le C++ est un techno vraiment complexe et qui nécessite de très bonnes bases en dev pour pouvoir prétendre avec un niveau pro. Après il existe de nombreux framework / sdk tel que QT pour rendre son développement moins archaïque...


Je pense en effet que si la syntaxe était plus user-friendly, beaucoup plus de gens s'y intéresserait d'avantage.

[Gugelhupf]

Je pense en effet que si la syntaxe était plus user-friendly, beaucoup plus de gens s'y intéresserait d'avantage.

Le C++ est devenu plus user-friendly avec C++11 et C++14, mais cela n'enlève rien à sa complexité qui prime sur le reste.

EDIT:
@Mouke

J'ignore si les dernières normes ont changé ça, en tout cas C++ (impose ?) permet la gestion mémoire avec les pointeurs et les malloc

malloc c'est du C, on n'est normalement pas censé utiliser cette fonction pour allouer de la mémoire en C++, il y a new, make_unique & les smart pointers.

[Bousk]

Actuellement en stage dans une banque, je me permets de compléter : Effectivement, point de C++. Du COBOL, du Natural, beaucoup de Java aussi (ça m'a surpris d'ailleurs le Java). Il me semble qu'il y a encore 75% de l'informatique financier qui fonctionne en COBOL dans le monde.
Néanmoins, le C++ ne me choquerait pas dans la finance.

Ok, oui,oui, NON !
Encore un qui oublie que ce bon vieux COBOL est le maitre incontesté dans les finances malgré sa discrétion.

Regarde un autre aspect de la finance : bourse, marchés, HFT; c'est du C++.

[Mouke]

@Mouke

malloc c'est du C, on n'est normalement pas censé utiliser cette fonction pour allouer de la mémoire en C++, il y a new, make_unique & les smart pointers.

Merci de l'info

[DonQuiche]

Je pense en effet que si la syntaxe était plus user-friendly, beaucoup plus de gens s'y intéresserait d'avantage.

Bof, pour moi ce n'est pas la syntaxe le problème, c'est son $#@$%*! de modèle de compilation à base d'inclusions et de substitutions de texte, et de headers. C'est lent, ça fait deux fois plus de fichiers, c'est fastidieux à gérer et ça produit des messages d'erreurs incompréhensibles en cascade quand le préprocesseur a rencontré sur une erreur. Et dans cinquante ans vous aurez encore des pelletées de biblios qui n'utiliseront pas de namespaces et colleront des dizaines de milliers d'identifiants aux noms cryptiques dans le global.

Chaque fois que je dois revenir au C++ c'est ça qui me me fait suer, cette sensation d'un retour en arrière de plusieurs décennies à cause de ce modèle de compilation. Mort aux en-têtes, mort aux inclusions, mort aux modèles de métaprogrammation conçus sans prendre en compte la difficulté du déboguage du processus de compilation. Je comprends tout à fait pourquoi ça a été fait ainsi à l'époque. Mais en 2014 ça fait mal. Ajoutez à ça d'autres vieilleries comme les digraphes (!) ou la gestion des chaînes de caractères.



Accessoirement, si on pouvait avoir une gestion automatisée de la mémoire et n'avoir à utiliser la gestion manuelle que lorsqu'on le désire, ce serait sympa. Mais a priori ça pose pas mal de problèmes, il faudrait que je regarde comment le D a abordé la chose (si je ne m'abuse il supporte les deux formules).

[Luc Hermitte]

1- Bof, pour moi ce n'est pas la syntaxe le problème, c'est son $#@$%*! de modèle de compilation à base d'inclusions et de substitutions de texte, et de headers. C'est lent, ça fait deux fois plus de fichiers, c'est fastidieux à gérer et ça produit des messages d'erreurs incompréhensibles en cascade quand le préprocesseur a rencontré sur une erreur. Et dans cinquante ans vous aurez encore des pelletées de biblios qui n'utiliseront pas de namespaces et colleront des dizaines de milliers d'identifiants aux noms cryptiques dans le global.

Chaque fois que je dois revenir au C++ c'est ça qui me me fait suer, cette sensation d'un retour en arrière de plusieurs décennies à cause de ce modèle de compilation. Mort aux en-têtes, mort aux inclusions, mort aux modèles de métaprogrammation conçus sans prendre en compte la difficulté du déboguage du processus de compilation. Je comprends tout à fait pourquoi ça a été fait ainsi à l'époque. Mais en 2014 ça fait mal.
2- Ajoutez à ça d'autres vieilleries comme les digraphes (!) ou la gestion des chaînes de caractères.

3- Accessoirement, si on pouvait avoir une gestion automatisée de la mémoire et n'avoir à utiliser la gestion manuelle que lorsqu'on le désire, ce serait sympa.

1- Il y a du travail en cours sur les modules. Il existe une version de clang qui implémente une tentative de modules pour avoir une preuve de fonctionnalité. Bref, des gens travaillent dessus pour le C++17. Il faudra encore attendre avant que tous les projets n'utilisent que ça et que les includes soient définitivement abandonnés.

2- Les digraphes viennent d'être dépréciés si je ne m'abuse.
Pour les chaines de caractères, ben il y a std::string. Pour l'UTF-8, c'est un chouilla plus compliqué. Il faut passer par des frameworks comme Qt ou boost.locale.

3- Si tu gères ta mémoire à la main, ton programme seras vite en inmaintenable en C++ -- un "grep -R delete * | wc -l" qui renvoie quelque chose dans une base de code C++ est un signe qu'il y a des choses à corriger. Une fois de plus, renseignez-vous sur le RAII. Depuis plus de 98 le principe est connu, depuis le début des années 2000 on a plein de shared_ptr<> dans plein de framework, et depuis 2011 il y a un type standard universel (pas forcément le meilleur pour tous les cas de figures, mais qui marche dans pratiquement tous les cas de figure).

Bref, NON on ne gère pas la mémoire à la main dans un programme C++. Pas si on le veut robuste et maintenable. Et non, cela n'impacte pas les perfs.

[DonQuiche]

1- Il y a du travail en cours sur les modules. Il existe une version de clang qui implémente une tentative de modules pour avoir une preuve de fonctionnalité. Bref, des gens travaillent dessus pour le C++17.

J'ignorais cela et c'est une excellente nouvelle, je te remercie. Le jour où ça sortira j'aurais peut-être envie de refaire du c++ (aujourd'hui je vois ça comme la croix et la bannière à chaque fois que je dois m'y remettre).

Une fois de plus, renseignez-vous sur le RAII.

Je sais parfaitement ce qu'il en est et ça reste de la gestion manuelle selon moi, bien qu'allégée : tu dois polluer ton code par des annotations mémoire systématiques, tu continues à te retrouver avec des fuites mémoire difficiles à comprendre, et il n'est pas rare du tout de devoir faire des changements profonds, notamment quand le dominateur d'un objet change (par exemple parce que tu as soudain besoin de persister ton objet plus longtemps que prévu, au-delà de la durée de vie de son précédent dominateur).

Et non, cela n'impacte pas les perfs.

Une incrémentation atomique (pour un shared_ptr) est loin d'être gratuite. Et ça ne va pas aller en s’améliorant avec la multiplication du degré de parallélisme du matériel. Mais c'est un point de détail dans la mesure où la solution bas niveau reste disponible.

unique_ptr, ça fait le café.

Dans les quelques cas où ça répond à ton besoin, oui.

[ternel]

Mais arrêtez avec cette idée de la gestion manuelle.

unique_ptr, ça fait le café.
Tu sais juste que tu alloues, exactement comme avec un new MachinBidule() de java
Et le reste, c'est géré tout seul.

La règle étant "au déscopage du unique_ptr", plutot que "quand le garbage collector tournera et que le compteur de référence sera tombé à 0".
Dans les deux cas, le développeur n'écrit aucun code de largage.

Par contre, je suis d'accord que parfois, les en-têtes se mettent en travers du chemin.
Surtout quand des bibliothèques sont mal codées. Mais ça, on en trouve aussi dans les autres langages, avec des défauts similaires.

J'ai galéré avec du java pendant des mois, parce que j'étais obligé d'utiliser une lib de 300 classes dans un seul package, avec énormément d'erreurs entre les visibilités protected et package.
Chose que le C++ ne peut pas connaitre.

[ternel]

J'en pense que c'est un langage qui s'offre des mécanismes de sureté très efficace, pour peu qu'on apprenne à les utiliser.
Le premier d'entre eux étant le RAII, et ses avatars les smart pointers.

C'est un outil qui fait bien ce qu'il est conçu pour faire: les applications complexes.

J'ai récemment participé à un repas troll débat sur les langages.
La conclusion que j'en tire est qu'il n'y a aucune possibilité d'un langage qui me manque en C++, alors que le contraire n'est pas vrai.

Je parle bien des fonctionnalités du langage, ou les bibliothèques standard réduites (STL, java.collection.*, etc) pas de leur bibliothèques étendues.
On n'avait volontairement pas considéré swing ou jdbc de java, tout comme on a ignoré Qt.

[smarties]

Il manque de quoi faire du web simplement. Les CGI sont peut être rapide mais c'est difficilement maintenable sur de grosses applications.

[robertledoux]

Il manque de quoi faire du web simplement. Les CGI sont peut être rapide mais c'est difficilement maintenable sur de grosses applications.

Tu peux te pencher du côté de "CppCMS" que j'utilise souvent (utilise boost et propose un système de template à la Twig) et "Wt".

[Invité]

Salut,
j'utilise ce langage depuis 5 ans déjà, non pas pour sa simplicité d'utilisation mais pour la résolution de problèmes plus complexe et de grosses applications multimédia à l'aide de la méta-programmation entre autre, ainsi que pour sa rapidité à l'exécution.
Je l'utilise également pour transférer des objets complexe en réseau.

Mais le nouveau standart du c++ n'est pas encore suffisant dans mon cas (même si il m'a rendu la tâche plus facile par moment, les choses peuvent vite devenir plus contraignante par la suite) :

Beaucoup de problèmes liés à ces nouvelles fonctionnalités :

-Les std::tuples_element et std::tuple_size ont besoin de la définition complètes des classes en compilation. (A cause de l'héritage fait dans ces différentes classes sûrement, je pense qu'il existe des implémentation similaire sans héritage mais je ne les connais pas et je ne sais pas si cela pourrait vraiment résoudre mes problèmes surtout si j'ai besoin d'appliquer un cast et un typeid.)
-Les macros ne suffisent pas toujours a résoudre des problèmes complexe, impossibilité de remplacer du texte dans un fichier ou bien d'en supprimer. (ça ne fait que du copier coller)
-Impossibilité de compiler une librairie sans passer le préprocesseur. (Il en parle ici mais malheureusement le lien de la lib est mort! : https://www.ideals.illinois.edu/bits...-2008-3009.pdf)
-Impossiblité de lire une constexpr dans un fichier et la passer en paramètre template. (Je ne sais pas si se sera possible avec le c++14.)
-Impossibilité d'inclure des fichiers en passant leurs noms à une macro variadique. (De plus il faut absolument connaître le nom des fichiers à inclure pour les passer à la macro lors de la compilation de la librairie.)

Bref je n'ai pas tout ses problèmes avec les autres langage comme par exemple le java, ou, lorsque je défini une classe, je peux utiliser un cast et tout ce que je veux même dans une classe template. (Par contre je ne pense pas que les templates variadique ça existe en java)
A vrai dire je crois que ce langage n'en a même pas besoin vu son système de réflexion et de serialization intégré, mais, le java perd en rapidité d'exécution face au c++ qui peut faire cela en compilation avec les template variadiques même si cela reste difficile et qu'il faut souvent passer par une librairie tierce.

Donc à partir du moment ou les librairies ainsi que les nouvelles fonctionnalités du c++ suiveront, le c++ restera un langage très utilisé.

[Astraya]

Le C++ n'a pas de garbage collector.

Je mettrais ça comme un avantage moi dans des situations métiers exigeantes. Pour faire de l'applicatif le garbage est un atout par contre j’avoue. Mais dans certains cas c'est plus une plaie qu'autre chose.

Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

C'est un mal pour un bien. Plus de développement, plus d’investissement, plus de travail pour nous :p. Non sérieusement, c'est sur que ça demande de l'adaptation coté code et coté compilateur mais le code roule directement sur le processeur et n'est pas interprété, donc il sera toujours plus performant.

Le C++ est complexe à apprendre et 10 ans après il y a toujours matière à apprendre sur C++ et à s'étonner. Mais l'avantage de C++ c'est que avec un code, on peut faire ce que font les autres langages, avec plus de travaille certes... Le C++ est performant et surtout je pense que c'est une langage mature qui à prouvé son efficacité dans beaucoup de situation.


Sinon C++ mieux c'est tout.

[Astraya]

Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Mais ou as tu choppé une idée pareil? les shaders sont basées sur quel langage selon toi? la seule différence de performance est du au faite que le programme est parallélisable à mort sur la CG, c'est juste une question matériel et pas software, met du C++ sur ta carte graphique et tu auras un résultat presque similaire. Essaye de comparer à du Java sur ta CG... ( je sais même pas si c'est possible)

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

Tout comme .NET, Haxe, Python...

[Mouke]

Le C++ est performant et surtout je pense que c'est une langage mature qui à prouvé son efficacité dans beaucoup de situation.

Je pense que tout est résumé.

Je serais surpris de savoir lesquels. Pour moi, des langages comme le C, D, Ada, ... sont presque toujours des alternatives tout a fait valables au C++.

Déjà j'ai du mal avec cette comparaison... Surement mon inexpérience. Je ne parle pas pour le D, je ne connais pas du tout ce langage. En ce qui concerne le C, ce n'est pas un langage Objet. Quant à Ada, il possède effectivement un aspect objet mais il n'était pas conçu pour à la base. C++ c'est justement l'enfant né du langage C et de la POO. En ce sens, je ne considère pas ça comme une alternative. J'envisage plutôt les différents paradigmes comme des solutions différentes en fonction des besoins.
Sinon, un domaine ou le C++ règne en maitre : Le jeu vidéo. Je ne connais aujourd'hui pas beaucoup de jeux qui ne sont pas en C++ (ce sont soit des vieux jeux, datant de l'ère DOS, soit quelques jeux indé). Et je me souviens des débuts de Minecraft... On a senti l'absence du C++....

Sinon, Uther, BASIC pour débuter ? Sérieusement ?

Je suppose qu'il parlait du Visual Basic.

[Battant]

Bonjour,

Je pense que l'intérêt de tel ou tel language dépends de cerain paramètre. Par exemple, nombre d'api dévoloppée pour ce language, la rapidité, l'indépendence ou non de cet api de la plate-forme comme par exemple qt ou encore les language java ou python.

Ai-je oublié des paramètres ?

Quel sont vos réactions ?

Salutations

[Matthieu Vergne]

C'est une évidence: un intérêt est toujours relatif a des préférences, qui peuvent être objectives (limites budgétaires, contraintes légales) ou subjectives (les goûts et les couleurs).

[Grom61736]

De ce fait, si l’on prête attention à l’embarqué, au domaine du traitement d’image, aux télécommunications ou encore aux applications financières, le C++ règne en maître

Ok, oui,oui, NON !
Encore un qui oublie que ce bon vieux COBOL est le maitre incontesté dans les finances malgré sa discrétion.

Mais effectivement, si on regarde un peu du coté de la recherche dans ces domaines là, c'est quasi exclusivement du C++.