4 pièce(s) jointe(s)
Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs
Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs sur les besoins en termes d’évolution du langage
Et les comparaisons avec des projets similaires
Cppfront c’est déjà 5 ans de travail dans l’ombre. C’est un projet personnel de Herb Sutter avec un objectif qui se résume en une phrase simple : proposer une évolution du C++ à la syntaxe dix fois plus simple que l’actuelle, plus sûre et avec le même niveau de support d’outils dont bénéficient les autres langages. Le directeur du comité de normalisation ISO C++ ouvre à peine le projet au public que celui-ci anime déjà les débats entre développeurs sur leurs attentes en matière d’évolution du langage désormais considéré par plusieurs comme une usine à gaz. L’initiative ne manque non plus de susciter les comparaisons avec des projets aux visées similaires.
En langage C++, A * b peut soit faire référence à une opération sur les pointeurs, soit à une multiplication. Cette seule remarque signifie pour un développeur que pour la mise sur pied d’un linter ou d’un outil de formatage de code en C++ il faudra analyser l’ensemble du code pour parvenir à construire un arbre d’analyse correct. C’est un exemple parmi une multitude pour illustrer la complexité du langage. C’est à ce type de problématiques auxquelles Cppfront vient s’attaquer. La documentation du projet n’est pas encore disponible. Une section exemples l’est néanmoins et permet déjà de se faire une idée des évolutions envisagées. On pourra observer que Cppfront se passe des #include.
Cppfront comme son nom l’indique se veut être un frontend à partir duquel la syntaxe en cours de gestation sera transformée en du C++20.
Cppfront n’est pas sans faire penser au projet Carbon positionné comme successeur expérimental du C++. L’objectif : explorer une direction future possible pour le C++ étant donné les difficultés à l’améliorer. Carbon est un nouveau langage qui vise à égaler les performances de C++ et à maintenir une interopérabilité bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les développeurs C++.
L'équipe promet en sus un certain niveau de traduction de source à source pour le code C++. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.
Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est un autre problème hérité. En outre, le comité C++ et le processus d'évolution sont orientés vers la normalisation plutôt que la conception, sont lents et ne parviennent pas toujours à prendre des décisions.
Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source : « Nous tenterons même de combler une énorme lacune dans l'écosystème C++ avec un gestionnaire de paquets intégré ». La feuille de route actuelle vise à terminer la version 0.1 du langage cette année, la 0.2 en 2023 et la version 1.0 en 2024 ou 2025.
Le langage Carbon sera familier aux développeurs C++ et C, mais il y a aussi de nombreuses différences. Les fonctions sont déclarées avec le mot clé fn et les variables avec var. Il existe également des tuples fortement typés. L'inférence de type est supportée par le mot-clé auto. Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs ; les seules opérations sur les pointeurs sont l'adressage et le déréférencement. Les classes supportent l'héritage simple mais pas l'héritage multiple.
Cppfront et Carbon sont des exemples d’une longue liste dans laquelle on retrouve d’autres initiatives comme Circle, Val et Dlang.
Source : cppfront, Herb Sutter
Et vous ?
:fleche: Êtes-vous développeur C++ ? Quelle plus-value reconnaissez-vous à ces différents projets ? Sinon qu’en attendez-vous ?
:fleche: Ces projets viennent-ils avec une plus-value véritable en comparaison à un langage comme le Rust considéré le futur pour ce qui est du développement d’applications système ?
Voir aussi :
:fleche: Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts
:fleche: Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google
:fleche: Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation
:fleche: Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
SI ce n'était pas herb sutter...
...je n'aurais même pas pris la peine de lire ce post. Et je suis déçu de l'avoir lu :?
Le C reste et restera la référence pour quelques temps encore. Le C++, j'y ai tâté lorsque j'étais jeune, mais qd je suis tombé sur le livre d'un certains "Andreisecsu" (pas sûre du nom), de 700 pages, rien que pour aborder les "templates", j'ai stoppé net "l'étude" de ce langage, dont seule la possibilité de faire de la POO (par rapport au C classique) m'intéressait (et c'était il y a 25 ans, je n'ose imaginer ce que tout ce brol est devenu...).
- Lorsque je veux faire simple, je le fait en Python + wxPython.
- Le C, c'est pour l'embarqué ou des petits émulateurs pour des petits/vieux processeur ou autre matériel basé dessus.
- Le Rust, j'avoue ne pas encore avoir regarder, je ne parlerais donc pas de ce que je ne connais pas.
- Le C++ est vite illisible (mon mantra : On écrit 1x on lit 100x le même code), donc j'ai laissé tomber.
- J'ai regardé à Haxe, pour faire des jeux, qui est un transpilateur, et le debug est juste horrible, comme tout ce qui n'est pas "natif". Enfin, c'était Il y a 5 ans, de bonne chose sont peut-être arrivées depuis. A revoir donc.
Pour en revenir à ce "nouveau" C++ (ce n'est pas le premier, java était déjà une tentative, mais est encore pire), le temps qu'il soit soit au point, normalisé, popularisé, je serais 6 pieds sous terre, je passerais donc mon tour :-)
Je crains que plus ce soit moins, et réciproquement
Le foisonnement de langages très similaires est une pure gabegie. Je ne peux nier que tel ou tel dialecte apporte certains avantages, ou corrige quelque faiblesse, mais la création de clones, forks, et autres variantes n'est que source de confusion. Ou de querelles de sectes.
Dans le cas de C++, selon mon expérience -limitée- d'amateur, je perçois une situation paradoxale dans l'évolution du langage: d'une part, il est repensé pour intégrer des concepts modernes de programmation, pour le plus grand bien de la productivité et de la sûreté du code (je veux dire contrôles à la compilation, lisibilité etc), d'autre part il cherche à éviter la création d'un langage alternatif, en assurant une compatibilité ascendante.
Le paradoxe est que cette compatibilité dont les bénéfices sont clairs pour assurer la maintenabilité de programmes initialisés en C++x et mis à jour en C++y, pour la pérennisation de bibliothèques etc, mais induisent en contrepartie d'une part des inhomogénéités dans le style de codage, d'autre part des syntaxes parfois alambiquées pour substituer un nouveau concept à un ancien, lequel reste d'actualité.
Personnellement je suis demandeur de conseils pour savoir quels (anciens) éléments du C++ je dois abandonner au bénéfice de quels nouveaux [merci de m'aiguiller vers des pages web en ce sens], les styles de programmation qu'il faut privilégier etc. [oui, je sais que les options de compilation peuvent m'aider en ce sens].
Pour caricaturer: supprimer (dans l'usage) instructions et syntaxes obsolètes pour que le langage soit plus simple à l'écriture et à la lecture est un plus. Créer des variantes de remplacement ou traitées par un préprocesseur Csuper vers C++ induit des complications mentales, dès lors que syntaxe et mots clés se ressemblent, et que le les niveaux d'abstractions sont du même ordre. Donc améliorer par cet artifice les caractéristiques de C++ apporte à mon avis plus d'inconvénients que d'avantages. Notamment, s'il reste nécessaire d'effectuer le débogage tant en Csuper qu'en C++.
Cela n'exclut pas que des outils ingénierie logicielle de plus haut niveau aient leur utilité.