Discussion :

[Madmac]

Qu'est-ce que tu racontes ? Les debuggeurs n'ont aucun problème à afficher le type et la valeur d'une variable déclarée avec auto. Pour au moins ce que j'utilise : MSVC, QtCreator, XCode.

Tant tu as une expression à droite de la variable qui n'a pas une valeur de retour de type auto. Désolé, mais je ne vois pas l'intérêt de ce truc lorsque l'on peut déjà faire du polymorphisme d'une façon plus sécuritaire, avec les objets et l'héritage.[/QUOTE]

C'est possible selon les cas. Slice existe depuis longtemps en C++. Et pleins de libs proposent cette fonctionnalité. Et les ranges aussi. Mais c'est pas parce que les devs Ruby trouvent ça élégant que les devs C++ aussi. Ou que c'est souhaitable d'avoir ça en C++. Si les devs C++ étaient intéressé, ça aurait été au moins proposé.

Je ne dis pas qu'il n'existe pas des outils pour travailler avec les intervalles. Je dis que la notation du C++ est archaïque. Il y a un tas de nouvelles idées qui sont apparus qui auraient pu être intégré au langage. Si Carbon ne rend pas la programmation plus sécuritaire ou plus aisée. Il vaut mieux considéré Rust que s'embarrasser à utiliser Carbon.

Et comme Google a l'habitude d'abonner ses projets sans les avoir finaliser. Ce truc est sans intérêt.

Tout le monde s'en tape de Linus. C'est un dev C, son opinion sur le C++ a autant de valeur que celle de mon boulanger.

Pourtant cela devrait être considéré dans cette discussion, puisque les "évolutions" sont presqu'uniquemen sur le volet C du langage, plutôt que le volet POO.

Hein ???

WebAssembly fonctionne sur un CPU virtuel. Une version évolué du Forth. Avec l'émergence de nouveau type de CPU qui ne sont pas basée sur le jeu d'instruction d'intel, il y a beaucoup d'application qui ne seront pas compiler en langage machine dans le futur.

[Madmac]

Je suis tomber sur une vidéo. Et le type expliquait qu'il ne fabriquait pas des accesseurs que si c'était absolument nécessaire. Et n'utilisait jamais la directive Private. Est-ce différent de l'enseigenement que vous avez reçu? Ayant débuté la programmation-object sur Pascal, j'ai toujours trouvé bizarre cette fabrication systématique d'accesseurs. Je crois que cette pratique pénalise la performance des programmes en C++

La gestion étroite de la mémoire avec le tas et la pile est-elle encore justifable pour des applications ?

[Pyramidev]

...

Je vois que tu as créé un fil dédié, donc j'ai répondu là-bas.

[TotoParis]

Si je connais plusieurs langages de programmation, C et surtout C++ me sont étrangers à 99%. Mais en comparant les deux exemples, j'ai trouvé Carbon bien plus lisible que C++, et j'ai compris le code que fait le premier, pour le C++, non pas tout.

[Fagus]

Si je connais plusieurs langages de programmation, C et surtout C++ me sont étrangers à 99%. Mais en comparant les deux exemples, j'ai trouvé Carbon bien plus lisible que C++, et j'ai compris le code que fait le premier, pour le C++, non pas tout.

Honnêtement, il y a pas grand chose de fondamentalement révolutionnaire entre les deux sources, sauf la volonté de remplacer les #include par un gestionnaire de dépendance.

Le reste, c'est surtout du sucre syntaxique et étrangement des régressions. La syntaxe du c++ est tordue, mais on s'y fait (à reculons pour moi...)

Le +

• std:: c'est la gestion des namespace un peu lourde où les fonctions standards ont un namespace dédié, alors que carbon les met dans l'espace de nommage courant.
• span<circle> c'est un template, la façon de gérer la généricité... alors que carbon semble utiliser une fonction du langage à la place.
• cout << : les créateurs du c++ on trouvé que c'était génial de surcharger << l'opérateur de décalage de bit, dans la fonction d'affichage cout, au lieu d'utiliser la notation fonction habituelle...

Le -

• auto a disparu (typage automatique). Bon, ensuite auto résout un problème très c++ d'avoir des types longs à saisir...
• quand carbon initialise son tableau de Circle, il faut préciser .r=valeur à chaque fois, alors même que .r est la seule variable en argument... c'est une étrangeté que je n'ai vue dans aucun autre langage.

[selmanjo]

En ce moment Rust n'est pas encore enseigné dans mon école supérieur !
Je me demande si mon école, en ce moment, en parlant de Rust, le verrouille.
La syntaxe Rustique ne me parait pas facile à appréhender, mais il y a des
efforts à fournir pour bien maîtriser ce magnifique langage de programmation.

Bien que je ne fais que débuter dessus !

Maintenant, dans le contexte du changement climatique , Carbon ne me semble
pas être une bonne alternative.

[Patrick Ruiz]

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

[epsilon68]

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.

[Madmac]

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.

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/d2.../#post11929238

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.