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 !

Le projet Carbon, un successeur expérimental du C++, explore une direction future possible pour le C++ étant donné les difficultés à l'améliorer
Et mise sur l'interopérabilité comme base de travail

Le , par Patrick Ruiz

101PARTAGES

18  0 
En février 2020, un vote crucial a eu lieu au sein du comité de normalisation du C++ sur la rupture de la compatibilité ABI en faveur de la performance. L’initiative principalement poussée par les employés de Google a échoué. Résultat : de nombreux Googlers ont cessé de participer à la normalisation du C++, ont démissionné de leur rôle officiel au sein du comité, et le développement de clang a considérablement ralenti. C’est de cette rupture que naît le projet Carbon annoncé comme successeur du C++. L’objectif : explorer une direction future possible pour le C++ étant donné les difficultés à l’améliorer. Le projet Carbon mise sur l’interopérabilité avec le C++ comme base de travail.

Lors d'un récent évènement dédié au langage C++ cette semaine à Toronto, Chandler Caruth, ingénieur logiciel chez Google, a présenté le langage Carbon, décrit comme un successeur expérimental du C++, suscitant un vif intérêt au sein de la communauté C++.

« Nous comprenons l'intérêt de la communauté pour cette keynote. Nous publierons l'enregistrement selon un calendrier accéléré », ont déclaré les organisateurs de la conférence sur Twitter. Carruth est responsable technique des principaux langages de programmation et de l'évolution des langages de Google. Il représente Google au sein du comité des normes C++ et contribue à LLVM et Clang.


Les développeurs de Carbon expliquent que si le C++ est le langage dominant pour les logiciels à performances critiques, son héritage et sa dette technique signifient que l'amélioration incrémentale du C++ est extrêmement difficile.

Une solution consiste à migrer vers d'autres langages tels que Rust, Kotlin, Swift ou Go, mais il est difficile de migrer vers ces derniers à partir du C++. De plus, dans certains cas, ces derniers présentent une surcharge de performance. 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++.

Pourquoi le C++ est-il difficile à améliorer ? Parce que le langage lui-même a commencé comme une bifurcation du C. Le langage C a 50 ans, il n'est donc pas surprenant qu'il y ait beaucoup d'héritage. 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é », peut-on lire dans les documents. 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.


La sécurité de la mémoire est une considération importante mais n'est pas l'objectif initial. « La différence entre l'approche de Rust et celle de Carbon est que Rust commence par la sécurité et que Carbon commence par la migration », peut-on lire dans la documentation. L'approche consiste à simplifier le langage afin de créer de l'espace pour les fonctionnalités de sécurité, puis à refaire l'ingénierie des fondations pour modéliser et appliquer la sécurité.

Le projet est sous licence Apache 2 avec des exceptions LLVM. L'équipe prévoit de créer une fondation open source et de lui transférer tous les droits liés à Carbon. « Notre objectif est que la configuration de la fondation soit similaire à d'autres projets open source tels que LLVM ou Kubernetes », ajoute-t-elle. Cependant, le projet exige actuellement que les contributeurs acceptent le CLA (contributor license agreement) de Google, ce qui peut poser problème à certains. Google finance également l'infrastructure de Carbon.

Sur la question de savoir pourquoi ne pas utiliser d’autres langages comme Rust, les têtes derrière l’initiative répondent : « Si vous voulez utiliser Rust, et que c'est techniquement et économiquement viable pour votre projet, vous devriez utiliser Rust ». Toutefois, la question de Rust est au cœur de la réussite future du projet Carbon. En effet, Rust est de l’avis de plusieurs observateurs en passe de devenir le langage de bas niveau standard. Néanmoins, on continue de compter plus de lancements de projets pilotés en C++ qu’en Rust et donc toute possibilité d’aller au-delà du C++ tout en conservant l’interopérabilité doit faire office de bonne nouvelle.

Source : Carbon

Et vous ?

Êtes-vous en accord avec l’argumentaire (le langage C++ est difficile à faire évoluer) qui a mené au lancement du projet Carbon ?
Êtes-vous développeur C++ ? Quelle plus-value reconnaissez-vous à ce projet ? Sinon qu’en attendez-vous ?
Le projet Carbon vient-il 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-nous-la !

Avatar de grunk
Modérateur https://www.developpez.com
Le 27/07/2022 à 11:35
Citation Envoyé par Madmac Voir le message

Moi ce qui me dérange le plus est qu'ils me semble pas avoir une idée très clair de la direction de l'évolution. Plutôt que de tenter de modifier le language, il devrait développer un surchose pour rendre le langage plus accessible et moins sujet aux fuites. J'ai jamais compris la raison pour laquelle, personne n'a développer une librairie pour faire du pure objet en C++..
Depuis C++11 tu as les smartpointer qui permettent dans la grande majorité des cas de ne pas faire de fuite mémoire puisqu'on à plus gérer la désallocation
Et au contraire je trouve que la direction de C++ est très claire => faciliter son utilisation et se rapprocher des langages de plus haut niveau dans l'utilisation tout en gardant les performances qui font le succès de C++.

Entre du C++98 et du C++20 c'est le jour et la nuit.

Pour moi le gros défaut de C++ c'est qu'il y'a des dizaines de façon différentes de faire la même chose en fonction du niveau d'optimisation qu'on veux atteindre. Ca rend les choses extrêmement compliqué et la courbe d'apprentissage plutôt raide.
Je me débrouille en C++ et parfois je me mets à lire le code de certaines lib (genre boost) et je me rend compte que je suis une sous merde parce que je ne comprend pas la moindre ligne de ce que je lis
12  0 
Avatar de AoCannaille
Expert confirmé https://www.developpez.com
Le 27/07/2022 à 11:55
Citation Envoyé par grunk Voir le message
Je me débrouille en C++ et parfois je me mets à lire le code de certaines lib (genre boost) et je me rend compte que je suis une sous merde parce que je ne comprend pas la moindre ligne de ce que je lis
ça me fait plaisir de lire ça, je suis exactement dans le même cas ^^' ça soulage un peu mon syndrome de l'imposteur
10  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 12/09/2024 à 18:34
Bjarne Stroustup, le créateur original de C++, a dénoncé lui-même la dérive qu'a prit le comité qui dirigent les évolutions de C++.
Ils leurs reproche d'ajouter des micro-fonctionnalités, qui ne sont utilent qu'à 0,01% des projets ou des développeurs, et qui pourrait être déjà fait avec l'existant. En fait, le C++ est maintenant piloté par un comité de gens certes très compétants, mais qui font de la masturbation intellectuel pour pondre des concepts qui sont très éloignés de ce dont ont besoin les développeurs dans le monde réel.

C'est malheureux, car voilà un langage qui avaient du succès, qui répondait à un besoin, mais qui va crouler sous sont propre poids.

BàV et Peace & Love.
7  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 20/07/2022 à 15:42
Très bon article

C++ est devenu clairement une usine à gaz compliquée et incompréhensible sauf pour quelques experts.
La syntaxe de Carbon semble ressembler pas mal à Rust, comment un tel projet pourrais t'il se positionner par exemple par rapport à C++, D et Rust ?
7  1 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 15/09/2024 à 10:42


Citation Envoyé par Brunoo  Voir le message
Pour remplacer le C++ n'y a-t-il pas déjà le langage D ? C'est en tout cas son ambition affichée.

D aurait pu être ce "nouveau C++", mais il n'a pas décollé, parce qu'au moment où il est sorti:

  • il n'était pas rétrocompatible avec le C
  • C++ n'était pas encore devenu le monstre qu'il est aujourd'hui, et a prit naturellement la relève.
  • Grâce à sa compatibilité avec le C, il avait déjà tout un éco-système, et une communauté autours de lui.


Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.
Car, selon moi, ce qui a fait le succès des langages comme Java et C# c'est aussi la lisibilité de leurs syntaxes.

La syntaxe, c'est une affaire de goût, d'habitude, mais surtout de lisibilité. Je dis souvent qu'on lit plus souvent son code qu'on ne l'écrit. Java, possédait (et possède toujours) des atouts, mais:

  • Il est très verbeux, rendant le code "surchargé" et difficile à lire.
  • Il tourne via une "machine virtuelle", qui même si elle possèce un JIT maintenant, ce n'était pas le cas à ses débuts.
  • Et à cause du fait qu'il tourne en s'appuyant sur une "machine virtuelle", il ne pouvait et ne peut pas être comparé au C/C++ qui peuvent compiler du code natif, pour plusieurs architecture. Il y a toujours un compilateur 'C' pour chaque architecture, de la plus petite à la plus grande.
  • Puis Python est arrivé est s'est fortement implenté. On dit qu'il est lent (parce que lui aussi tourne sur une machine virtuelle), mais il sait très facilemment utiliser du code 'C', ce qui fait que tout traitent "lourd" est souvent exécuté à la vitesse du 'C'.


Pour C#, c'est un peu le "java" de microsoft. La puissance de microsoft est derrière ce langage, mais lui aussi tourne sur une "machine virtuelle", même s'il a maintenant aussi un JIT, il ne peut en rien être comparé (tout comme Java), question vitesse, à C/C++. Il a prit de l'importance et est très utilisé, car il y'a microsoft derrière, est ça "rassure" les entreprises quant à sa pérénité.

Le Go, je ne connais pas, donc j'évite de faire des commentaires sur une technologie qui m'est inconnue.

Et je ne parle même pas du fait que l'adoption d'un nouveau langage tien aussi au fait que chaque instruction soit non seulement documentée mais surtout accompagnée d'un exemple pratique et utile (codes snippets), afin de faciliter la mise en pratique.

Il n'y a pas que ça, il faut tout un écosystème autours d'un langage. De la doc, oui, mais aussi des librairies, des éditeurs, bref, toute une floppée d'outils.
Il faut aussi créer tout une communauté, qui perdure et sait acceuillir les développeurs qui se pencheront sur un langage.

Et un petit dernier pour la route Il n'y a pas langage qui soit adapté à toutes les situations. Il ne me viendrait pas à l'idée de faire une grosse application en 'C'. C'est plutôt le C++ qui serait utilisé dans ce cas. Dans le domaine de l'embarqué, le seul langage que tu es certains d'avoir, c'est le 'C'. Dans le domaine banquaire, c'est toujours du COBOL qui est utilisé. Certains ont bien tenté de ré-écrire les vielles application COBOL en java ou en C++, mais tout les essais ont échoués, car c'est très difficile de reconstruire un système qui fonctionne à l'identique.

Et il y a une grosse masse de code 'C' dans la nature, et on ne remplacera pas celui-ci du jour au lendemain.

Actuellement, quelques langages se démarquent des autres:

  • Python chez les "data scientist", et les "ingénieurs", car il est trés simple à écrire et à relire, et à tout ce qu'il faut pour les satisfaire question librairires (numPy par exemple) pour s'affranchir sa "relative" lenteur.
  • lua, est lui aussi un langage "dynamique" comme Python, et est simple à utiliser. Sa machine virtuelle est aussi plus rapide que celle de Python, car c'est une "register based VM", là ou Python/Javan reposent sur des "stack based VM".
  • C# pour ceux qui ne veulent être "rassuré" par le fait que Microsift soit derrière.
  • Le 'C' reste indispensable grâce à sa vitesse, son éco-système, et qu'il reste le plus rapide, car très proche de ma machine. Son désavantage, c'est que si on ne fait pas très attention, on peut vite introduire des vulnérabilités. Mais dans l'embarqué, c'est toujours 'LA' référence, et avec la base de code installée, il est encore là pour très longtemps.
  • C++, car (tout comme le C), il il peut produire du code natif et est de ce fait très utilisé. Et il a profité de la vague POO à ses début. Il est également très installé.
  • COBOL reste utilisé dans le domaine bancaire.


Et puis, il y'a maintenant le petit nouveau (enfin, a quand même 10 ans) Rust qui peut pratiquement égaler C/C++ niveau vitesse, mais qui est nettement plus sécurisé niveau gestion mémoire et évite pas mal d'erreurs qu'on peut faire en C/C++, car le langage (et son compilateur) fournira des erreurs et ne compilera pas un code dangereux.

C'est je pense le seul langage (qui produit du code machine) qui peut/pourra rivaliser avec le C/C++. Je suis en train de me pencher dessus, et pour un vieux développeur 'C' comme moi, sa "syntaxe" me déroute énormément (mais avec le temps, ça viendra), et il faut parfois se battre avec le compilateur pour qu'il accepte de compiler un code, car les différents verrous qu'il possèdent pour être "sécure" sont parfois "lourds" a digérer pour les vieux développeurs 'C', qui savent ce qu'il font. Mais on fait tous des erreurs, et si le langage permet d'en éviter, ça ne peut être d'une bonne chose.

[B]Rust[B] est déroutant, et il faut s'accrocher et persévérer, car oui, les concepts qu'il aborde sont traités différement que d'autres language, mais rend le code plus "sécure".

Mais, je le répête, il n'y a pas de langage meilleurs qu'un autres. Il faut choisir son outils par rapport à ses besoins. On utilise un marteau pour enfoncer un clou, et un tournevis pour viser une vise. L'inverse n'aurait pas de sens.

BàV et Peace & Love.
6  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 25/07/2022 à 8:56
Ma pensée sur le sujet :

https://xkcd.com/927/
7  2 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 12/09/2024 à 11:07
Quels autres aspects du langage C++ aimeriez-vous voir améliorés dans les futures versions ?
Un gestionnaire de dépendances, je n'ai fais plus de C++ depuis 2006 mais j'ai parfois cherché à compiler certains programmes et c'est une galère à chaque fois car la bibliothèque manquante n'était pas clairement notée : il faut se baser sur le nom du fichier ou chercher dans le makefile et ça demande du temps à chaque fois.
5  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 20/07/2022 à 23:37
Citation Envoyé par archqt Voir le message
Je ne vois pas l'intérêt si la syntaxe ressemble à Rust, autant prendre Rust qui vise aussi la performance.
Les auteurs de Carbon ont répondu dans leur FAQ : Why not Rust?

Je ne copie-colle pas la réponse en entier, mais seulement le début :

If you can use Rust, ignore Carbon

If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.

We believe that Rust is an excellent choice for writing software within the pure Rust ecosystem. Software written in Rust has properties that neither C++ nor Carbon have. When you need to call other languages from Rust, RPCs are a good option. Rust is also good for using APIs implemented in a different language in-process, when the cost of maintaining the FFI boundary is reasonable.
4  0 
Avatar de Astraya
Membre émérite https://www.developpez.com
Le 21/07/2022 à 11:36
Citation Envoyé par raphchar Voir le message

J'aime le fait d'avoir un fichier header pour référencer les classes/fonctions de manière compacte.
Et le fait qu'il soit recompilé pour CHAQUE translation unit aussi? Que l'on dois jouer avec les namespaces et les collisions de noms? Et donc qu'on se retrouve avec des préfixes dans les noms pour comblé un problème du langage?

Citation Envoyé par raphchar Voir le message

J'aime le fait d'avoir le contrôle en c++. Je peux créer ma structure de donnée qui utilise des pointeurs nus et est efficace pour mes besoins. Et je peux utiliser des pointeurs intelligents quand je ne veux pas me casser la tête.
Et le mainteneur ou collègue qui passe derrière dois se plonger dans la tête de l'ancien programmeur? C'est pas une vision égoïste du travaille? "Moi je comprends ce que j'ai fais c'est pas compliqué, ils sont nulles les autres si il arrive pas a passer derrière".
Après plusieurs années à faire du C++, mon principal sujet quand je code c'est "comment protégés mon code", "comment le rendre maintenable sans effort" sans ajouter de commentaire partout en disant "Attention c'est super compliqué".

Citation Envoyé par raphchar Voir le message

Mais ouais, le c++ n'est pas sûr pour le novice. On peut faire n'importe quoi avec les pointeurs ou autre.
Il n'est sûr pour personne, et le novice pense toujours être un dieu en C++ jusqu’à ce qu'il se plante et généralement c'est dans la semaine après son embauche...

Citation Envoyé par raphchar Voir le message

Alors oui, on peut créer un langage pour virer tout potentiel problème de sécurité. Mais on va perdre en performance. Et c'est ainsi qu'on se retrouve avec des programmes qui consomment beaucoup trop pour ce qu'ils font.
Renseigne toi avant de dire ça. Rust est plus rapide que C++ sur de nombreux points ET apporte de la sécurité. La contrepartie n'est pas la performance, c'est plus d'effort de la part du programmeur pour penser correctement son application en terme de design, architecture et utilisation mémoire.
D'autres aspect rentre en compte, comme l'aliasing de pointeur.

Citation Envoyé par raphchar Voir le message

Vous voulez améliorer le c++, j'ai des pistes sans créer un nouveau langage :
Améliorer la compilation des templates.
Changez l'ABI si ça vous chante.
Je t'invite à leur proposer tes solutions = > https://isocpp.org/std/meetings-and-...s-and-mailings

Citation Envoyé par raphchar Voir le message

La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose
Ah bon? sur de sur? alors où placer std::initializer_list? Comment faire std::vector<int> v = {1,2,3}; sans ça? c'est pourtant dans la std... et l'implémentation dépend de la librairie standard qui est fortement lié au compilateur.
Et ou placer std::construct_at qui est le seul autorisé à construire un objet à un emplacement mémoire spécifique dans une évaluation constante (aka constexpr)?

Le C++ est coincé, il se débloque en ajoutant un peu plus de flou et de complexité partout mais ça ne fait que grossir la complexité et au final le ralentir dans certains cas.
Un peu comme les instructions x86 des processeurs Intel ou AMD qui sont toujours ajoutés, jamais retiré, jamais modifié. Résultat... plus de 1300 instructions dans les CPU X86 contre ~40 pou RISC-V 32bits et ~500 pour ARM 32 bits... Et pour faire la meme chose.
5  1 
Avatar de 23JFK
Inactif https://www.developpez.com
Le 21/07/2022 à 14:40
C'est la mode du moment de tout "révolutionner" avec des var et de fn, et pourquoi pas aussi des begin et des end... Mais au final, l'original restera dominant et ces forks vulgaires péricliteront avec leurs utilisateurs.
5  1