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 !

Carbon va-t-il remplacer le C++ ? Le projet Carbon 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

34PARTAGES

14  0 
Le langage Carbon est encore expérimental. La feuille de route indique la période 2025-2026 pour la sortie de la version 0.2 qui marquera le terme de l’expérience. La version 1.0 est attendue après 2026. L’effort est porté par des ingénieurs logiciels de Google qui ont cessé de participer à la normalisation du C++, ont démissionné de leur rôle officiel au sein du comité. Motif : un vote (au sein du comité de normalisation) sur la question de la rupture de la compatibilité ABI en faveur de la performance ne leur a pas donné raison. C’est de cette mésentente que naît le projet Carbon annoncé comme successeur du C++.

Les développeurs de Carbon expliquent que certes, le C++ est le langage dominant pour les logiciels à performances critiques, mais son héritage et sa dette technique signifient que son amélioration incrémentale est une tâche très ardue.

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. 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.

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é.


Les développements autour du langage Carbon interviennent dans où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

Après 31 ans, un deuxième langage fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

Source : Semaphore

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 :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

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

Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 01/03/2023 à 21:46
j'ai l'impression, après avoir essayé un peu, que cppfront serait mieux pour migrer du source c++ vers un sous ensemble plus sain.

De plus, il n'y a rien de fonctionnel dans Carbon, ils sont juste dans le design.
3  0 
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 12/03/2023 à 0:47
Citation Envoyé par grunk Voir le message
Ce n'est pas un ramasse miette comme on peut en trouver en java mais simplement une comptge de référence par chaque pointer. Quand le nombre de référence tombe à 0 le pointer s'auto détruit. Ca ajoute un léger overhead par rapport à un pointer normal (en terme de taille) mais dans la majorité des cas c'est acceptable. Les situation cible ou ca peut être un problème sont de toute manière généralement développées en C..
Ce que tu me décrit ressemble énormément au ramassage Mark and Sweep (https://en.wikipedia.org/wiki/Tracin...mark-and-sweep). Et c'est très ancien et c'est un modèle qui n'est pas très performant. Oracle a developpé un modèle concurrent, mais je doute qu'il soit du domaine publique.

Citation Envoyé par grunk Voir le message

A la vue de tes exemples je pense que tu ne pratique pas suffisamment le C++ ou en tout cas pas du C++ dit moderne.
Oui clairement C++ ne deviendra pas Python,Ruby ou un langage fonctionnel en terme de syntaxe (et tant mieux j'ai envie de dire) , mais on est bien loin de ce qu'il a pu être.
Effectivement, je trouve cela souffrant. Si la rareté des librairies n'étaient pas un problème important, je l'abandonnerais complètement au profit d'Objective C ou de D. Je ne comprend pas pourquoi ces deux langages soit autant ignoré.

Mais je trouve que la syntaxe n'a pas évolué en introduisant des simplifications que l'on pourrait considéré comme du typage implicite. Si ce fait un boucle d'une longueur de 255, est-ce que c'est vraiment nécessaire de spécifier que c'est un "unsigned Int8"?

Pourquoi il n'existe pas de Class String et PString Ascii et Unicode optimisés? Basé meilleurs algos existants.

À mes yeux, faire de la programmation object à la façon d'Objective C devrait-être une possibilité avec une simple directive de compilation. Après tout, je ne crois pas qu'à l'exception de l'analyseur syntaxique qu'il existe une véritable différence entre les deux compilateurs.

Plutôt que de réinventer la roue à chaque fois, je trouve que l'accent devrait être sur les transpileurs.

Dans ce fil, je décris en quoi les objets sont plus conviviale pour le programmeur en Objet-Pascal: https://www.developpez.net/forums/d2136938/general-developpement/langages-programmation/l-on-enseigne-poo-conforme-realite/#post11929238

Citation Envoyé par Pyramidev Voir le message
Je vois que tu as créé un fil dédié, donc j'ai répondu là-bas.
J'étais très occupé à l'époque, je viens de répondre.
0  0