Pourquoi le langage C++ demeure incontournable 35 ans après sa sortie ?
Son créateur Bjarne Stroustrup revient sur les atouts du langage
Le 2014-08-28 13:30:26, par Arsene Newman, Expert éminent sénior
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 ?
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 ?
-
Luc HermitteExpert éminent séniora- Hum ...
Code : 1
2
3
4
5
6
7// Java TypeDeTroisKilometreDeLong var = new TypeDeTroisKilometreDeLong(args); // C++ TypeDeTroisKilometreDeLong var{ args }; auto var = TypeDeTroisKilometreDeLong {args }; auto var = make_unique<TypeDeTroisKilometreDeLong>(args);
Je pourrai aussi critiquer l'absence de surcharge d'opérateurs qui rend les opérations mathématiques au combien plus agréables à écrire en C++.
Je pourrai aussi critiquer l'absence d'héritage qui ne permette pas d'empêcher la substituabilité syntaxique (ou comment dériver une liste triée d'une liste sans violer le LSP).
Alors certes il y a des cas où le Java permet peut-être d'écrire des choses plus simplement, mais il y en a beaucoup d'autres où le C++ permet d'écrire des codes utilisateurs bien plus simplement.
b- Pas en standard, mais il existe plusieurs bibliothèques/frameworks qui ajoutent des GC. Perso, le RAII me suffit tout le temps. Et si ce sigle t'es inconnu, c'est probablement que tu connais pas assez le C++ pour le critiquer de façon éclairée. Si tu sais ce qu'est le RAII, alors tu sais à quel point on n'a pas besoin de GC pour gérer correctement *toutes* les ressources en C++ (et pas que la mémoire)
c- On en a autant besoin que ce tu as besoin de l'héritage multiple.
d- Oui, c'est vrai. D'ailleurs la JVM est compilée pour chaque plateforme ...
e- Sauf des OS industrialisés (Java coute trop cher pour vraiment partir dans cette direction), et sauf pour la JVM (car à un moment, il faudra bien une couche basse pour implémenter les GC qui fournissent de la mémoire ; et je doute que les implémentations de cela aillent s’embêter à le faire en assembleur)
f- Je sais, don't feed the troll, mais que voulez-vous, on est trolldi après tout.le 29/08/2014 à 11:54 -
IradrilleExpert confirméJe te l'accorde.
Question de point de vu surement, ce sont pour moi les deux plus gros avantages du C++ sur Java.
Tout comme une JVM doit être présente sur toute machine cible pour le Java, mais oui, le fait que le langage ne soit pas multiplatforme est un défaut (il est tout à fait possible d'écrire du code portable cependant).
Tous les algos ne s'y prettent malheuresement pas.
Même une JVM ?le 29/08/2014 à 1:17 -
foetusExpert éminent séniorBof, même si la grammaire du C++ est ambiguë, il n'y pas vraiment de truc tordu.
Juste des fonctionnalités qui rajoutent "une autre forme de coder"
Mais tu peux coder ton propre ramasse-miette. Eugen Systems le fait pour leurs jeux
Cela se défend. Il y a le RTTI et des vieilles techniques (comme mettre le nom de la classe dans la classe par exemple)
Mais en règle générale, lorsque tu fais cela en C++, cela commence à sentir mauvais pour ton code
C'est même mieuxLorsque tu vois les différences entre les plateformes tu m'étonnes que tu ne puisses pas
Vieux débat entre CPU généraliste (comme les CPUs) et un CPU spécialiste (comme les GPUs)
Et mine de rien, faire un programme full-shader n'est pas possible (ce sont les pilotes qui redirigent le travail si je ne dis pas de bêtises).
Et OpenCL n'arrive pas à décoller
N'importe quoi. Un langage == un domaine d'application.
Tu t'imagines qu'au lieu du javascript ce soit du C++
Et inversement, tu t'imagines coder un logiciel (un truc sérieux) en javascript ou Ruby voire Pythonle 28/08/2014 à 22:27 -
DonQuicheExpert confirmé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).le 29/08/2014 à 12:16 -
koala01Expert éminent séniorJe suis justement occupé à la rédaction d'un ouvrage qui tend à démontre le contraire (pour ce qui est des débutants du moins).
Il est donc préférable de se former avec un autre langage pour apprendre plus en douceur et de faire des prototypes avec un autre langage qui permet de coder plus rapidement sans se soucier de tous les menus détails, qui peuvent être pris en compte plus tard.
Si tu penses, par exemple, aux pointeurs et à la gestion manuelle de la mémoire, tu as (en partie) raison : il ne sert à rien de s'inquiéter de ces détails lors de l'apprentissage. Mais C++ permet de s'en passer jusqu'à ce qu'on aborde les problèmes liés au point réellement neuf du paradigme oo : la substituabilité et son pendant que sont les comportements polymorphes.
Par contre, si tu considère les principes SOLID ou la loi de déméter comme de "menus détails", tu mérites sans doute de te faire pendre par les pieds au dessus d'un feux de joie
Il est tout à fait vrai que C++ part du principe que le développeur sait ce qu'il y a toujours une bonne raison à ce qu'il fait, privilégiant à chaque fois la fonctionnalité utile (à condition d'être correctement utilisée) à la sécurité d'une fonctionnalité non fournie.
D'autres langages ont une philosophie différente, mais c'est sans doute cette différence de philosophie qui permet le mieux de choisir le langage "qu'on préfère"le 01/09/2014 à 16:30 -
GugelhupfModérateurLe 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 mallocle 28/08/2014 à 14:34 -
AstrayaMembre chevronnéCar aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.
Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.le 29/08/2014 à 10:02 -
SaverokExpert éminentAs-tu au moins lu l'article ??
L'auteur dit très clairement que le C++ n'est pas adaptés aux applications "modernes"
Java (ou autre langage de haut niveau) n'a pas les mêmes domaines d'applications que le C++
A chaque domaine, ses outils
Il y a eu plusieurs projets de faire des systèmes embarqués avec Java
Ca a été des échecs car Java est trop haut niveau justement et qu'il a fallu tailler dans le vifs pour l'alléger lui faisant perdre tous ses avantages par l’allègement de son jeu d'instruction. Et le tout, avec des perf moindre que le C++
La simple existence de la JVM provoque une consommation mémoire (et donc de batterie) incompatible avec les systèmes embarqués.
Je suis développeur Java depuis 10 ans et je kiffe ce langage mais ça n'empêche pas d'être conscient de ses faiblesses et de ses capacitésle 29/08/2014 à 10:50 -
ternelExpert éminent séniorMais 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.le 29/08/2014 à 12:38 -
koala01Expert éminent séniorSalut,
je suis d'accord que c'est caché à l'utilisateur, mais, à ton sens, que fait l'instruction import de java?
Cela se fait au niveau de la JVM, mais, il n'y a rien à faire, cette instruction ne fait pas grand chose d'autre que ce que fait la directive préprocesseur #include au final, même si je t'accorde que c'est enrobé de manière à ce que l'utilisateur d'une classe n'ait pas **trop** à s'en inquiéter
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).
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.
La grosse différence entre java et C++ est que, au moins, tu as le choix de payer le cout de ce comptage de référence ou non, selon tes besoins, alors qu'il t'est imposé en java
Dans les quelques cas où ça répond à ton besoin, oui.
A mon sens, il est beaucoup plus sain de se dire que, quoi qu'il arrive, il n'y a jamais qu'un et un seul objet qui, à un instant T, peut décider de détruire une ressource -- quitte à transférer de temps en temps cette responsabilité -- plutôt que de se dire que cette décision doit être collégiale.
Il y a, bien sur, des cas dans lesquels tu ne peux éviter le recours au shared_ptr, mais, à titre personnel, je ressent toujours ces situations comme un échec conceptuel, car je préfère de loin utiliser les unique_ptr, et que, je préfère encore purement et simplement éviter le recours aux pointeurs à chaque fois que faire se peutle 29/08/2014 à 14:21