IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

12PARTAGES

30  0 
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 ?

Êtes-vous développeur C++ ? Quelle plus-value reconnaissez-vous à ces différents projets ? Sinon qu’en attendez-vous ?
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 :

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

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

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

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SimonKenoby
Membre habitué https://www.developpez.com
Le 19/09/2022 à 9:48
C'est marrant comme on aime critiquer la syntaxe du C et C++, alors que moi personnellement de tout les langages que j'ai pu faire c'est l'une de celle que je préfère.
9  1 
Avatar de TJ1985
Membre expérimenté https://www.developpez.com
Le 24/09/2022 à 11:19
C'est marrant, en lisant les points mentionnés j'en arrive à me demander pourquoi les gens passent autant de temps et dépensent autant d'énergie pour ré-inventer Pascal. Ca semble une remarque en l'air, mais jetez un oeil, vous risquez une belle surprise.

Sur le fond, je m'interroge sur le foisonnement de langages à la syntaxe proche. C'est un excellent moyen d'introduire de la confusion où elle est le plus malvenue. Et puis, des trucs tiennent quand même de la croyance : Pourquoi déclarer une fonction par "fn" et non par "function" ? Six caractères de plus, c'est trop aujourd'hui, ça ne tient plus sur la carte perforée ?

Durant une trentaine d'années j'ai entre autres assuré la maintenance d'applications écrites des générations avant moi, sur d'autres systèmes. Ce qui a permis de faire durer ce code était sa lisibilité relative et la stabilité de la plateforme cible (VMS - COBOL, Pascal, C). Aujourd'hui, j'ai une impression de grande agitation, et de très peu d'efficacité.

J'ai l'impression que des démarches comme celle décrite dans l'article ne tiennent aucun compte du rapport coût/bénéfice, du gain réel qu'on peut en attendre. Si un langage est sujet à erreurs, qu'il est cryptique, que sa syntaxe est ambiguë, etc etc, il faut se poser les bonnes questions : Pourquoi le conserver, pourquoi à toute force vouloir le faire évoluer sans changer ses fondamentaux ?

Aujourd'hui, C est un langage fondamental puisqu'il s'agit du dialecte parlé par toutes les plateformes. Mais on pourrait aussi s'arrêter là, un langage bas niveau suffit, et former les gens à l'utiliser correctement, ce qui semble encore loin d'être fait. On pourrait aussi admettre qu'il est plus important de pouvoir se concentrer sur la compréhension d'un domaine et de ses problèmes plutôt que sur les spécificités de la x-ième version du langage choisi pour les résoudre.

Un bon développeur qui maitrise à fond un langage rustique vaut toujours mille fois mieux qu'un mauvais développeur qui ne maitrise pas le langage le plus sophistiqué du moment.
7  0 
Avatar de onilink_
Membre chevronné https://www.developpez.com
Le 19/09/2022 à 9:55
@SimonKenoby
Ici la critique adresse plus la difficulté de parser la syntaxe (qui est très contextuelle).

Bien que je déteste la syntaxe proposée (je la trouve difficile à lire et à écrire), l'idée de faire un frontend pour avoir une syntaxe bien plus simple à parser/traiter est très intéressante.

Maintenant en tant que développeur qui veut parser du C++, est ce qu'il ne serait pas plus simple de directement utiliser le "Clang Code Model"...?
De ce que j'ai pu voir, les IDE qui ont une bonne prise en charge des outils de refactoring, coloration etc... utilisent ça (Qt Creator par ex).
3  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 21/09/2022 à 14:07
Citation Envoyé par BakaOnigiri Voir le message
Bon, et maintenant je me demande comment un décrit un langage de programmation, Typescript et Cppfront qui sont une autre manière de décrire du code et qui deviennent un autre code avant la phase de compilation sont-ils des langages de programmations ? Hum ... bon cela semble évident que oui, mais je fait tout de même une distinction entre ces 2 outils et Carbon, Go, Rust ...
En fait, la distinction n'est pas au niveau des langages, mais des outils : TypeScript et CppFront ont des transpilateurs (qui transforment en JavaScript ou C++), les autres ont de vrais compilateurs. Rien n'empêche que Clang se mette à lire directement le code en CppFront, sans passer par une transpilation en C++. D'ailleurs, le C++ a commencé comme ça : une transpilation vers le C, avec cfront, avant d'avoir un langage plus complet/complexe et de vrais compilateurs.
3  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 19/09/2022 à 14:38
Citation Envoyé par BakaOnigiri Voir le message
C'est marrant, pour un article qui doit nous présenter Cppfront, 50% présente Carbon
Certes, mais si tu veux plus de détails sur Cppfront tu peux toujours aller voir la source, le fait d'ajouter Carbon dans l'article est très pertinent pour comparer et élargir la problématique générale, c'est donc purement une valeur ajoutée de l'article, et en fait la vidéo proposée dans l'article est très intéressante à cet égard
3  1 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 19/09/2022 à 16:30
Citation Envoyé par BakaOnigiri Voir le message
Peut être, sauf que si j'ai tout bien compris, Carbon serait plus un nouveau langage (au même titre que Go, Rust, ...) mais avec une grande compatibilité C++ (lors de la phase d'édition de liens), alors que Cppfront sera transcodé en C++20 (tout comme Typescript qui deviens du JS), donc même si cela ressemble à un nouveau langage, cela n'est que "juste" une surcouche.
C'est des solutions différentes mais c'est pour répondre à la même problématique, à savoir l'avenir du C++, et ça fait débat, aussi bien sur les communautés US qu'ici.
2  0 
Avatar de BakaOnigiri
Membre averti https://www.developpez.com
Le 21/09/2022 à 12:56
Citation Envoyé par OuftiBoy Voir le message
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 :-)
Sauf que Cppfront n'est pas comme Java qui est un langage différent, Cppfront est "convertis" en C++ avant la phase de compilation. Enfin c'est ce que j'ai compris de l'article. Pour moi, Cppfront est au C++ ce que Typescript est au Javascript, une surcouche qui est traduit dans le langage d'origine avant la compilation.
2  0 
Avatar de Axel Mattauch
Membre actif https://www.developpez.com
Le 24/09/2022 à 12:58
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é.
2  0 
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 19/09/2022 à 15:35
la dernière fois où j'ai participé à une discussion ici sur la syntaxe du c++, ça c'est plutôt mal passé, les participants ne voyant pas les problèmes de cette "magnifique" syntaxe, je ne suis pas sur que ça ait beaucoup changé entre temps.

ou alors peut être que, parce que c'est Sutter (entre autres) qui avance un mouvement, on commencera peut être à voir les problèmes ...

le comité, faudra que je retrouve le texte, ne voulait pas entendre parler de révision du langage, craignant l'apparition de dialectes du c++.
à force de ne jamais retenir une solution cohérente à un même problème et de superposer des couches pour garder une relative compatibilité (et encore) de syntaxe (et surtout garder des vestiges du c, qui lui ne se prive pas de tout casser), on en arrive à avoir des constructions alambiquées parce que "on ne veut rien casser, enfin sauf des fois, ça dépendra de la chance et du sens du vent".
1  0 
Avatar de BakaOnigiri
Membre averti https://www.developpez.com
Le 19/09/2022 à 16:01
Citation Envoyé par Pierre Louis Chevalier Voir le message
Certes, mais si tu veux plus de détails sur Cppfront tu peux toujours aller voir la source, le fait d'ajouter Carbon dans l'article est très pertinent pour comparer et élargir la problématique générale, c'est donc purement une valeur ajoutée de l'article, et en fait la vidéo proposée dans l'article est très intéressante à cet égard

Peut être, sauf que si j'ai tout bien compris, Carbon serait plus un nouveau langage (au même titre que Go, Rust, ...) mais avec une grande compatibilité C++ (lors de la phase d'édition de liens), alors que Cppfront sera transcodé en C++20 (tout comme Typescript qui deviens du JS), donc même si cela ressemble à un nouveau langage, cela n'est que "juste" une surcouche.

Bon, et maintenant je me demande comment un décrit un langage de programmation, Typescript et Cppfront qui sont une autre manière de décrire du code et qui deviennent un autre code avant la phase de compilation sont-ils des langages de programmations ? Hum ... bon cela semble évident que oui, mais je fait tout de même une distinction entre ces 2 outils et Carbon, Go, Rust ...
1  0