Discussion :

[Brunoo]

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

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

[OuftiBoy]

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.

[archqt]

Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.

Quand j'ai dit cela à propos de Rust, en disant que c'était dommage de ne pas avoir conservé une syntaxe "C like" on m'a "moinsé" sans donner de contre argument. On est donc d'accord, et effectivement si java, C# ont décollé c'est en partie grâce à cela. Il suffit de regarder le Go, très performant aussi, il a plus de mal à décoller.

[Uther]

Quand j'ai dit cela à propos de Rust, en disant que c'était dommage de ne pas avoir conservé une syntaxe "C like" on m'a "moinsé" sans donner de contre argument. On est donc d'accord, et effectivement si java, C# ont décollé c'est en partie grâce à cela. Il suffit de regarder le Go, très performant aussi, il a plus de mal à décoller.

En effet certaines choses ne sont pas exactement identiques mais tout l’intérêt de faire un nouveau langage et que faire des choix mieux adaptés par défaut et pas se trainer des spécificités d'un vieux langage. C'est un gros défaut du C++ qui se traine l'héritage du C.

Rust n'a jamais prétendu être un surensemble de C++. Il a quand même une syntaxe relativement inspirée du C++ (acolades, point-virgules, opérateurs, espace insignifiant, le let n'est pas très différent du auto,...). Il y a des spécificités mais elles font sens quand on apprend les fonctionnalités spécifiques du langage.

[23JFK]

Qui peut croire que les politiques savent ce qui est bon pour une industrie? Rust est poussé par une communauté actuellement anormalement puissante dans les milieux de pouvoirs ; ce n'est pas un mauvais langage, mais il n'est pas taillé pour la rentabilité/productivité et les faits d'armes de ce langage se résument à avoir réécrit des choses qui existent déjà et sans réelle nécessité de réécriture, on peut admirer la complexité du pattern mémoire résultant d'une compilation Rust réussie, louer son contrôle de l'espace mémoire... et cela répond sûrement aux besoins de certains domaines de pointe (aérospatial, armée...) Mais la seule chance pour Rust de dépasser le C++ c'est que ce dernier devienne aussi compliqué à appréhender que l'outsider.

[OuftiBoy]

Mais la seule chance pour Rust de dépasser le C++ c'est que ce dernier devienne aussi compliqué à appréhender que l'outsider.

Malgrè tout le mal que j'ai a comprendre (je ne parle pas d'utiliser, simplement de comprendre) ce que Rust apporte, le C++ n'a pas eu besoin de Rust pour commencer son auto-destruction. Le code C++ est un des plus laid et compliqué possible, sachant à peine donner un message d'erreur correcte et compréhensible. J'ai un autre avis sur le C, parce que je l'ai pratiqué toute ma vie, et il sera là pour encore très longtemps. Le C++ disparaîtra bien avant le 'C', qui reste compréhensible et n'a pas tendance a évoluer dans tous les sens.

BàT et Peace & Love.

[Uther]

Qui peut croire que les politiques savent ce qui est bon pour une industrie ? Rust est poussé par une communauté actuellement anormalement puissante dans les milieux de pouvoirs

Je suppose que vous parlez du rapport de la maison blanche préconise d'éviter les langage memory unsafe, il ne pousse pas uniquement Rust. Je ne connais pas d'autre exemple d'institution d'état demandant l'utilisation de Rust. Bien sur que les politiques n'y connaissent rien eux même, mais il s'appuient bien évidement sur des rapports de vrais experts de la sécurité.

ce n'est pas un mauvais langage, mais il n'est pas taillé pour la rentabilité/productivité et les faits d'armes de ce langage se résument à avoir réécrit des choses qui existent déjà et sans réelle nécessité de réécriture

On peut tout a fait dire la même chose de C++ qui n'a pas permis de faire quoique ce soit qui n'était pas possible avec C sans réelle nécessité de réécriture.
Pour ce qui est de la productivité, c'est discutable. Rust nécessite certes d'apprendre des notions qui n'existent pas en C++, mais ne nécessite pas d'en apprendre d'autre spécifiques au C++. Les contraintes qu'il ajoute à la compilation permettent d'éviter des erreurs couteuses en débogage. Google qui est le seul a ma connaissance a avoir mesuré la productivité entre les différent langage qu'il utilise, sur un nombre significatif d'équipes, a classé Rust au niveau de Go, deux fois plus productif que C++.

[23JFK]

... le C++ n'a pas eu besoin de Rust pour commencer son auto-destruction. Le code C++ est un des plus laid et compliqué possible, sachant à peine donner un message d'erreur correcte et compréhensible. J'ai un autre avis sur le C, parce que je l'ai pratiqué toute ma vie, et il sera là pour encore très longtemps. Le C++ disparaîtra bien avant le 'C', qui reste compréhensible et n'a pas tendance a évoluer dans tous les sens.

BàT et Peace & Love.

Je vous concède que les évolutions incessantes et discutables du C++ sont pénibles à suivre/comprendre. Mais le C++ reste malgré tout 95% compatible C. A vrai dire, il reste permissif et vous permet d'organiser votre code sans vous obliger à avoir recours à toutes ces évolutions syntaxiques et ajouts du "modern C++". On peut très bien s'en sortir en ne l'utilisant que comme un C enrichi du concept de classes, et d'ailleurs, ça peut parfois être la seule manière d'obtenir un code plus rapide.

...Google qui est le seul a ma connaissance a avoir mesuré la productivité entre les différent langage qu'il utilise, sur un nombre significatif d'équipes, a classé Rust au niveau de Go, deux fois plus productif que C++.

Le problème c'est que Google a mis le doigt dans le "Go Woke Go Broke" et que Rust, pour une raison qui m'échappe encore, est devenu "LE langage de programmation" de cette communauté, alors donc... Peut-on encore se fier ici à l'avis de Google ? (souvenez-vous du plantage magistral de leur IA wokisée Google_Gemini).

[Uther]

Je vous concède que les évolutions incessantes et discutables du C++ sont pénibles à suivre/comprendre. Mais le C++ reste malgré tout 95% compatible C. A vrai dire, il reste permissif et vous permet d'organiser votre code sans vous obliger à avoir recours à toutes ces évolutions syntaxiques et ajouts du "modern C++". On peut très bien s'en sortir en ne l'utilisant que comme un C enrichi du concept de classes, et d'ailleurs, ça peut parfois être la seule manière d'obtenir un code plus rapide.

Le soucis c'est que le code compatible avec le C, c'est du code pas vraiment recommandé de nos jour en C++ par la plupart des gens qui enseignent le C++, et pourtant il peut toujours se mélanger avec du code dit moderne, que ça soit volontairement ou par inadvertance. De même si on veut que C++ produise du code vraiment sécurisé, cela demandera aussi de nouvelles fonctionnalités avec de nouveaux usages qui créeront de fait un nouveau dialecte.
C'est pour ça que parfois, partir sur un nouveau langage cohérent peut être plus intéressant que de trainer un héritage lourd, avec différents dialecte que certains trouveront des améliorations alors que d'autres les voient comme des régressions.

Le problème c'est que Google a mis le doigt dans le "Go Woke Go Broke" et que Rust, pour une raison qui m'échappe encore, est devenu "LE langage de programmation" de cette communauté, alors donc... Peut-on encore se fier ici à l'avis de Google ? (souvenez-vous du plantage magistral de leur IA wokisée Google_Gemini).

C'est fou cette propension a certains adeptes du C++ a ramener à la religion ou au Wokisme l'usage de Rust quand en face on parle de technique et de chiffres qui n'ont rien a voir. Le fait d'être black, gay, trans ou autre ne change pas la productivité, contrairement au langage que l'on utilise. Les utilisateurs de Rust restant d'ailleurs, comme pour presque tout ce qui touche a l'informatique, principalement des hommes blancs hétéro.

[23JFK]

...
C'est fou cette propension a certains adeptes du C++ a ramener à la religion ou au Wokisme l'usage de Rust quand en face on parle de technique et de chiffres qui n'ont rien a voir. Le fait d'être black, gay, trans ou autre ne change pas la productivité, contrairement au langage que l'on utilise. Les utilisateurs de Rust restant d'ailleurs, comme pour presque tout ce qui touche a l'informatique, principalement des hommes blancs hétéro.

Le problème de cette communauté n'est pas qu'elle existe, le problème c'est qu'une partie d'elle réseaute de fou furieux et que ceux-là sont clairement à l'origine de 90% de toute la m*rde avec des ramifications politiques que l'on voit actuellement. Quand on voit Disney, Ubisoft, Budweiser, ChatGPT et plus encore Google Gemini, etc... On ne peut plus faire semblant de ne pas voir l'éléphant au milieu du couloir. Mais ça enlève rien aux qualités et défauts de Rust, juste que la hype Rust fait manifestement partie de cette bouillie politique et que ça va finir par poser les problèmes qui arrivent toujours avec ces activistes.

[OuftiBoy]

Uther

C'est pour ça que parfois, partir sur un nouveau langage cohérent peut être plus intéressant que de trainer un héritage lourd, avec différents dialecte que certains trouveront des améliorations alors que d'autres les voient comme des régressions.

Je suis 100% d'accord avec Uther dans cette description. Le C++, à ces débuts, était beaucoup plus "light" que maintenant. C'est l'ensemble des évolutions qui sont parfois souvent faites sur un langage, qui, petit à petit, en essayant de tout faire, qu'un langage peut très mal évolué. C'est ce qui est arrivé au C++. Sa syntaxe est devenue horrible.

Je suis un développeur C depuis 40 ans, mais je trouve bien qu'à un moment donné, on change pour un langage complètement différent, en repartant d'une feuille blanche, et éviter les erreurs faites avant par d'autres langages. Le 'C' a été crée il y a 50 ans, et devait à ce moment, être vu comme un assembleur de haut niveau, pour économiser les ressources, et exploiter au maximum le hardware. C++ a prit la relève pour des projets plus important, en amenant la POO (qui selon la manière dont elle est implémentée dans le langage, où suivant la manière dont elle est utilisée par un développeur, peut être une bonne chose, mais aussi produire du code très difficile a maintenir et a faire évoluer). D'ailleurs, la première version C++ étaient nommé 'C with class'. Puis il a évoluer, et est devenu un langage obèsse à la syntaxe très difficile.

J'ai du mal avec 'Rust', parce qu'il est loin de mes habitudes, mais c'est un langage (que je ne maîtrise pas encore aussi bien que le 'C'), mais c'est, depuis des décénnies, le seul langage qui pourraient enterrer le C++. Faire du C avec le C++, ça n'a pas beaucoup d'intêret.

Pour le 'C', ce n'est pas la même problématique.

BàT et Peace & Love.

[Stéphane le calme]

Vers un C++ plus sûr ? Avec les extensions Safe C++, la communauté C++ veut répondre aux défis modernes de la sécurité des logiciels
Dans un contexte où plusieurs entités recommandent de remplacer C++ par des alternatives

Depuis plusieurs années, le langage de programmation C++ est critiqué pour ses failles de sécurité, notamment les erreurs de gestion de mémoire comme les débordements de tampon et les utilisations après libération. Face à ces défis, la communauté C++ a décidé de réagir avec une proposition : les extensions Safe C++.

Un besoin pressant de sécurité

La sécurité des logiciels est devenue une priorité pour les développeurs et les organisations du secteur public et privé. Des langages comme Rust, C#, et Go ont gagné en popularité grâce à leurs caractéristiques de sécurité mémoire intégrées. Cependant, le C++ reste un pilier dans le développement de systèmes performants et bas niveau. Pour répondre à cette demande croissante de sécurité, la communauté C++ a élaboré les extensions Safe C++.

Qu’est-ce que les extensions Safe C++ ?

Les extensions Safe C++ visent à introduire des fonctionnalités de sécurité mémoire dans le langage C++. Ces extensions incluent des mécanismes comme le vérificateur d’emprunt (borrow checker) pour prévenir les erreurs d’utilisation après libération et des analyses d’initialisation pour garantir la sécurité des types. Ces outils permettent aux développeurs d’écrire du code plus sûr sans sacrifier les performances et la flexibilité du C++.

Une collaboration significative

Le projet Safe C++ est le fruit d’une collaboration entre la C++ Alliance et des ingénieurs renommés comme Sean Baxter. Cette initiative marque une étape importante dans l’écosystème C++, en répondant aux critiques et en s’adaptant aux exigences de sécurité actuelles.

Vinnie Falco, président et directeur exécutif de l'Alliance C++, a déclaré :

« Je suis heureux d'annoncer que l'Alliance C++ a formé un partenariat avec Sean Baxter, un ingénieur de renom, pour développer la proposition Safe C++ Extensions.

« Il s'agit d'une proposition révolutionnaire qui ajoute des fonctionnalités de sécurité de la mémoire au langage de programmation C++.

« Cette collaboration marque une étape importante dans l'écosystème C++, car le besoin d'un code sûr n'a jamais été aussi pressant. Compte tenu de l'importance croissante de la sécurité et de la fiabilité des logiciels, les développeurs sont soumis à une pression de plus en plus forte pour adopter des pratiques de codage plus sûres. Les extensions Safe C++ visent à répondre à ce besoin critique en introduisant de nouvelles fonctionnalités qui empêchent les erreurs courantes liées à la mémoire.

« Nous sommes ravis de travailler avec Sean Baxter sur cette initiative cruciale. Les Safe C++ Extensions représentent une avancée majeure pour rendre le C++ plus sûr et plus efficace, tout en préservant les performances et la flexibilité du langage.

« La bibliothèque standard sécurisée est un élément clé de la proposition d'extensions C++ sécurisées. Cet ajout important à la bibliothèque fournira aux développeurs des implémentations robustes et sans danger pour la mémoire de structures de données et d'algorithmes essentiels. En intégrant ces composants dans la bibliothèque standard C++, nous pouvons nous assurer que le nouveau code est écrit en gardant à l'esprit la sécurité dès le départ.

« L'Alliance C++ et Sean Baxter sollicitent les réactions des développeurs, des chercheurs et des autres parties prenantes sur la proposition d'extensions C++ sûres. Ce processus de collaboration permettra d'affiner la portée du projet et de s'assurer qu'il répond aux besoins les plus urgents de l'écosystème C++ ».

S'assurer que le code est exempt de bogues liés à la sécurité de la mémoire

Cette collaboration arrive à point nommé car, depuis deux ans, les organisations des secteurs privé et public poussent les programmeurs à écrire de nouvelles applications et à réécrire les anciennes dans des langages à mémoire sûre tels que C#, Go, Java, Python et Swift, mais surtout Rust parce que c'est un langage de systèmes de bas niveau performant.

Après deux ans de coups de bâton sur la sécurité de la mémoire, la communauté C++ a publié une proposition visant à aider les développeurs à écrire un code moins vulnérable.

La proposition Safe C++ Extensions vise à résoudre le talon d'Achille du langage de programmation vulnérable, à savoir la difficulté de s'assurer que le code est exempt de bogues liés à la sécurité de la mémoire. « Il s'agit d'une proposition révolutionnaire qui ajoute des fonctions de sécurité de la mémoire au langage de programmation C++ », a déclaré jeudi Vinnie Falco, président et directeur exécutif de l'Alliance C++. « Cette collaboration marque une étape importante dans l'écosystème C++, car le besoin d'un code sûr n'a jamais été aussi pressant ».

L'ingénieur logiciel Alex Gaynor a soulevé la question en 2019, notant que la majorité des vulnérabilités graves dans les grandes bases de code proviennent de failles de sécurité de la mémoire telles que les débordements de mémoire tampon et l'utilisation après la libération. « Les données confirment, encore et encore, que lorsque les projets utilisent des langages peu sûrs pour la mémoire comme le C et le C++, ils sont accablés par une avalanche de vulnérabilités de sécurité qui en résultent », a-t-il écrit.

La sécurité de la mémoire est ensuite devenue un sujet de discussion courant dans les articles universitaires et les conférences techniques. En septembre 2022, Mark Russinovich, directeur technique de Microsoft Azure, a appelé à l'abandon de C et C++ et à l'adoption de Rust.

Quelques mois plus tard, la NSA a adopté une position similaire. En 2023, la sécurité de la mémoire est devenue un sujet courant, couvert par Consumer Reports.

Les personnes impliquées dans le C++ se sont mises sur la défensive

Il y a deux ans, en réponse à l'appel de M. Russinovich à se débarrasser de C/C++, le créateur de C++, Bjarne Stroustrup, a déclaré : « Nous pouvons désormais garantir une sécurité parfaite des types et de la mémoire dans ISO C++ ».

Cette déclaration a toutefois été accueillie avec un certain scepticisme. Josh Aas, cofondateur et directeur exécutif de l'Internet Security Research Group (ISRG), qui supervise une initiative de sécurité de la mémoire appelée Prossimo, a déclaré l'année dernière que s'il est théoriquement possible d'écrire du C++ sûr pour la mémoire, cela ne se produit pas dans le monde réel parce que le C++ n'a pas été conçu dès le départ pour la sécurité de la mémoire.

La proposition Safe C++ Extensions vise à répondre à cette critique et à satisfaire la demande du secteur public en matière de sécurité de la mémoire émanant de la NSA et des autres agences de renseignement « Five Eyes », de l'Agence américaine pour la cybersécurité et les infrastructures (CISA), de la Maison Blanche et de la DARPA.

En août, Gaynor est revenu sur le sujet de la sécurité des mémoires en soulignant que, s'il est logique d'essayer de rendre le C++ plus sûr, il doute de la mesure dans laquelle cela est possible.

« Il est clair, je pense, que des améliorations substantielles de la sécurité sont possibles pour le C++ », écrit-il. « En particulier, la résolution complète de la sécurité spatiale semble être à portée de main. Hélas, je pense qu'il est tout aussi clair que rendre le C++ aussi sûr que Swift, Go ou Rust n'est pas quelque chose que nous savons faire, et il ne semble pas probable que nous soyons capables de trouver une solution simple. »

Néanmoins, la proposition Safe C++ Extensions vise à essayer. Reconnaissant le chœur désormais assourdissant des appels à l'adoption de langages de programmation à mémoire sécurisée, les développeurs Sean Baxter, créateur du compilateur Circle, et Christian Mazakas, de l'Alliance C++, affirment que si Rust est le seul langage de programmation de niveau système populaire sans garbage collection qui offre une sécurité mémoire rigoureuse, la migration du code C++ vers Rust pose des problèmes.

« Rust manque de surcharge de fonction, de modèles, d'héritage et d'exceptions », expliquent-ils dans la proposition. « Le C++ n'a pas de traits, de relocalisation et de vérification des emprunts. Ces différences sont responsables d'un décalage d'impédance lors de l'interfaçage des deux langages. La plupart des générateurs de code pour les liaisons interlangages ne sont pas en mesure de représenter les caractéristiques d'un langage en termes de caractéristiques d'un autre langage ».

Bien que la DARPA tente de développer de meilleurs outils automatisés de conversion de C++ en Rust, Baxter et Mazakas affirment que dire aux développeurs C++ vétérans d'apprendre le Rust n'est pas une solution - un point qu'un mainteneur du noyau Linux axé sur le C a récemment soulevé.

« L'étrangeté de Rust pour les développeurs C++ de carrière, combinée à la friction des outils d'interopérabilité, rend difficile le renforcement des applications C++ par la réécriture des sections critiques en Rust », affirment-ils. « Pourquoi n'y a-t-il pas de solution directement dans le langage à la sécurité de la mémoire ? Pourquoi pas un Safe C++ ? »

L’avenir du C++

Avec l’introduction des extensions Safe C++, le C++ se positionne pour rester pertinent et compétitif face aux nouveaux langages de programmation. Cette évolution montre que le C++ peut s’adapter et évoluer pour répondre aux besoins modernes de sécurité et de fiabilité des logiciels.

En définitive, la communauté du C++ contre-attaque avec une proposition audacieuse qui pourrait bien redéfinir l’avenir du développement logiciel. Les extensions Safe C++ représentent une avancée majeure pour un langage qui continue de jouer un rôle crucial dans le monde de la programmation.

Sources : Safe C++ (1, 2), Alex Gaynor (1, 2), NSA, Maison Blanche

Et vous ?

Pensez-vous que les extensions Safe C++ peuvent réellement rivaliser avec les langages modernes comme Rust en termes de sécurité ? Pourquoi ou pourquoi pas ?
Quels sont, selon vous, les principaux défis que la communauté C++ devra surmonter pour adopter largement les extensions Safe C++ ?
Comment voyez-vous l’avenir du C++ avec l’introduction des extensions Safe C++ ? Cela pourrait-il changer votre perception du langage ?
Avez-vous déjà rencontré des problèmes de sécurité mémoire dans vos projets C++ ? Comment les avez-vous résolus ?
Quels autres aspects du C++ aimeriez-vous voir améliorés pour renforcer la sécurité et la fiabilité des logiciels ?
Pensez-vous que les entreprises adopteront rapidement les extensions Safe C++ ou resteront-elles prudentes face à ces nouvelles fonctionnalités ?
Comment comparez-vous les efforts de la communauté C++ pour améliorer la sécurité avec ceux d’autres communautés de langages de programmation ?

[NotABread]

Je trouve l'initiative intéressant surtout si on peut garder l'héritage du C++ et une compatibilité avec le C.

Après, peut-on encore dire qu'il s'agit de C++ ? Cela ajoute une syntaxe et des notions ne faisant pas partie de C++. De plus, si par défaut toute fonction C++ sont marquées unsafe à moins de spécifier le contraire, est-ce que l'on ne se retrouverait pas avec de grosse lourdeur à exposer l'existant au safe C++ ? Il faudrait que j'en lise plus sur ce projet

[Mathis Lucas]

Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils »
une alternative controversée proposée par le créateur du langage

Le comité du langage C++ travaille depuis plusieurs années sur des moyens d’améliorer la sécurité mémoire du langage, souvent critiqué pour ses vulnérabilités. En parallèle, Rust est devenu un modèle en matière de sûreté grâce à ses propriétés et son système de vérification stricte des accès mémoire. Le projet Safe C++ visait à créer un sous-ensemble du langage garantissant « une sécurité mémoire comparable à celle de Rust ». Mais la proposition vient d'être mise de côté, car elle n'est pas populaire auprès du comité. La priorité est donnée aux « Profils », un projet qui vise aussi à améliorer la sécurité du langage C++, mais sans s'inspirer du modèle de Rust.

La sécurité des logiciels est devenue une priorité pour les développeurs et les organisations du secteur public et privé. Des langages comme Rust, C#, et Go ont gagné en popularité grâce à leurs caractéristiques de sécurité mémoire intégrées. Cependant, le C++ reste un pilier dans le développement de systèmes performants et bas niveau. Pour répondre à cette demande croissante de sécurité, la communauté C++ a élaboré les extensions Safe C++.

Qu’est-ce que les extensions Safe C++ ?

Les extensions Safe C++ visent à introduire des fonctionnalités de sécurité mémoire dans le langage C++. Ces extensions incluent des mécanismes comme le vérificateur d’emprunt (borrow checker) pour prévenir les erreurs d’utilisation après libération et des analyses d’initialisation pour garantir la sécurité des types. Ces outils permettent aux développeurs d’écrire du code plus sûr sans sacrifier les performances et la flexibilité du C++.

Le projet Safe C++ est le fruit d’une collaboration entre la C++ Alliance et des ingénieurs renommés comme Sean Baxter. Cette initiative marque une étape importante dans l’écosystème C++, en répondant aux critiques et en s’adaptant aux exigences de sécurité actuelles. Sean Baxter a déclaré que le projet permettrait aux développeurs C++ d'obtenir la sécurité mémoire de Rust, mais sans nécessiter l'apprentissage d'un nouveau langage.

« Safe C++ empêche les utilisateurs d'écrire du code non fiable. Cela inclut des fonctionnalités d'intelligence à la compilation telles que la vérification des emprunts pour éviter les bogues d'utilisation après libération et l'analyse d'initialisation pour la sécurité des types », a-t-il déclaré. Safe C++ permettrait une migration incrémentielle du code, car il ne s'applique qu'au code dans un contexte sécurisé. Le code non sécurisé existant fonctionnerait comme avant.

Abandon de Safe C++ et le choix des « Profils »

Lors de ses dernières discussions, le comité C++ a décidé de mettre la proposition Safe C++ de côté pour concentrer ses efforts sur une autre approche : les « Profils ». Imaginée par Bjarne Stroustrup, le créateur du C++, cette stratégie consiste à définir différents Profils de garanties (sécurité, performance, contraintes de compilation) que les développeurs pourraient appliquer selon leurs besoins, plutôt que d’imposer un modèle de sûreté unique.

« Le groupe de travail sur la sécurité et la sûreté a voté pour donner la priorité aux Profils plutôt qu'à Safe C++. Demandez aux responsables des Profils de vous tenir au courant. Safe C++ n'est pas poursuivi », a commenté Sean Baxter, auteur du compilateur Circle C++ de pointe, en juin de cette année.

Quelles sont les raisons du rejet du modèle Rust-like ? À en croire les discussions sur le sujet, le modèle inspiré de Rust imposait des contraintes jugées trop lourdes pour l’écosystème C++. L’idée d’annoter les fonctions comme sûres ou pures, avec l’obligation qu’elles n’appellent que d’autres fonctions elles-mêmes sûres, a été perçue comme trop radicale et difficilement compatible avec la base de code existante et l’évolution progressive du langage.

Incertitude quant à l'avenir du projet Safe C++

Bien que Sean Baxter affirme que le projet Safe C++ est abandonné, la question ne semble pas totalement trachée. Erich Keane, membre du comité C++ et coprésident du groupe de travail sur l'évolution du C++ (EWG), a déclaré que « la proposition de Sean Baxter a reçu un vote d'encouragement, environ la moitié (20/45) des personnes ayant encouragé le document de Sean Baxter, et 30/45 ayant encouragé le travail sur les Profils (avec 6 neutres) ».

Il semble donc que Sean Baxter soit invité à poursuivre ses efforts, et de nombreux membres du comité aimeraient le voir poursuivre ses efforts pour normaliser cette question ». En réponse, il a déclaré : « le modèle de sécurité inspiré de Rust n'est pas populaire auprès du comité. Poursuivre mes efforts ne changera rien à cela. Les Profils ont remporté le débat ».

Il a ajouté que les principes d'évolution du C++ adoptés par l'EWG incluent la déclaration suivante : « nous devrions éviter d'exiger une annotation de fonction sûre ou pure qui implique sémantiquement qu'une fonction sûre ou pure ne peut appeler que d'autres fonctions sûres ou pures ». Il s'agit là, selon lui, d'un « désaccord irréconciliable en matière de conception». La coloration des fonctions sûres est au cœur du modèle de sécurité inspiré de Rust.

Qu'est-ce que les « Profils » de Bjarne Stroustrup ?

Les Profils ont pour but de définir des modes de C++ qui imposent des contraintes sur la manière dont vous utilisez le langage et la bibliothèque, afin de garantir certaines propriétés de sécurité. Il s'agit principalement de contraintes au moment de la compilation, bien que dans la pratique, certaines vérifications puissent être mises en œuvre à l'aide de fonctionnalités de bibliothèque qui ajoutent une surcharge d'exécution limitée.

Au lieu d'introduire des constructions de langage entièrement nouvelles, les Profils limitent principalement les fonctionnalités et les utilisations existantes. L'idée est que vous pouvez activer un profil, et tout code qui l'utilise accepte de se conformer aux restrictions. Si vous ne l'activez pas, tout fonctionne comme avant. Il est donc rétrocompatible.

« Je pense que Safe C++ était plus ambitieux : introduction d'une nouvelle syntaxe, de qualificatifs de type, de contextes sûrs ou non sûrs, etc. Certains membres du comité ont estimé que c'était trop lourd, et les Profils sont considérés comme une voie plus pragmatique. La principale objection est évidente : on pourrait dire que les Profils imposent moins de restrictions que ce que Safe C++ visait à fournir », souligne l'ingénieur logiciel Simone Bellavia.

« À la lecture des commentaires ici et là, on constate une résistance visible au sein de la communauté à l'adoption du modèle Rust. Si vous voulez écrire comme Rust, écrivez simplement en Rust. Historiquement, le C++ est un langage qui a souvent emprunté des fonctionnalités à d'autres mondes et les a intégrées en lui-même. Dans ce cas, je pense que des sous-ensembles de sécurité du C++ existent déjà de manière informelle », a-t-il ajouté.

Controverses entourant les « Profils »

Pour ceux qui écrivent en Rust, Safe C++ présente de nombreuses similitudes avec Rust, parfois avec des ajustements pour s'adapter à la conception du C++. De plus, comme C++ dispose déjà d'une énorme base de « code non sécurisé », Safe C++ doit fournir des mécanismes permettant de mélanger le code sécurisé et non sécurisé, et de migrer progressivement. En ce sens, toutes les fonctionnalités sécurisées de Safe C++ sont facultatives.

Toutefois, Bjarne Stroustrup, préconise les Profils qui, selon lui, signifient : « je veux cet ensemble de garanties et elles seront alors appliquées ». Selon Bjarne Stroustrup, « ce qui est regrettable, c'est que le comité de normalisation s'est embrouillé et n'a pas garanti que cela serait inclus dans le C++ 26 ».

Cela dit, les Profils sont également controversés, certains se plaignant, par exemple, que « les Profils ne ressemblent à aucune solution établie qui fonctionne, n'ont pas d'implémentation et n'ont pas été intégrés à la norme C++ 26 au début de l'année, le comité ayant préféré demander un autre livre blanc à ce sujet ».

Sean Baxter ne pense pas que les Profils permettront d'atteindre cet objectif. « J'aurais mis en place des Profils s'ils avaient une chance de fonctionner », a-t-il déclaré. Il a ajouté que « toute la bibliothèque standard est dangereuse ». « J'ai proposé une std2 rigoureusement sécurisée, mais elle a été rejetée ».

La controverse autour de la manière de rendre le C++ plus sûr pourrait signifier qu'il vaut mieux se tourner vers un autre langage, qu'il s'agisse de Rust ou d'un autre langage tel que le projet expérimental Carbon de Google, dont la feuille de route indique qu'il pourrait proposer une version 1.0 du langage après 2028.

Conclusion

La proposition Safe C++ visait maintenir le langage C++ pertinent et compétitif face aux nouveaux langages de programmation. L'objectif était de monter que le C++ peut s’adapter et évoluer pour répondre aux besoins modernes de sécurité et de fiabilité des logiciels. Cependant, les personnes impliquées dans le développement du langage se sont mises sur la défensive et le comité des normes C++ a finalement opté pour les Profils comme alternative.

Les Profils semblent moins radicaux et plus faciles à adopter, un C++ plus sûr par défaut sans imposer le modèle Rust qui vise à s'attaquer aux pièges les plus courants du C++. La principale objection est évidente : on pourrait dire que les Profils imposent moins de restrictions que ce que Safe C++ visait à fournir.

En somme, le développement du sous-ensemble Safe C++ strict est mis en pause. L’effort se concentrera désormais sur les Profiles, une solution plus pragmatique, même si certains craignent qu’elle n’apporte pas un niveau de sécurité aussi élevé que celui promis par l’approche inspirée de Rust.

Sources : Safe C++, billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la proposition Safe C++ ?
Que pensez-vous des raisons potentielles de l'abandon de la proposition Safe C++ ?
Que pensez-vous des Profils, l'alternative proposée par le créateur du langage Bjarne Stroustrup ?
Selon vous, quelle approche contribuerait à rendre le C++ plus adapté aux besoins modernes de sécurité et de fiabilité des logiciels ?

Voir aussi

Vers un C++ plus sûr ? Avec les extensions Safe C++, la communauté veut répondre aux défis modernes de la sécurité des logiciels dans un contexte où plusieurs recommandent de le remplacer par des alternatives

C++ sous stéroïdes : Bjarne Stroustrup présente des « profils » renforcés par des lignes directrices pour la sécurité des ressources et des types afin de garantir que le code est contemporain et sûr

Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google

[OuftiBoy]

Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils », une alternative controversée proposée par le créateur du langage.

Le comité du langage C++ travaille depuis plusieurs années sur des moyens d’améliorer la sécurité mémoire du langage, souvent critiqué pour ses vulnérabilités. En parallèle, Rust est devenu un modèle en matière de sûreté grâce à ses propriétés et son système de vérification stricte des accès mémoire. Le projet Safe C++ visait à créer un sous-ensemble du langage garantissant « une sécurité mémoire comparable à celle de Rust ». Mais la proposition vient d'être mise de côté, car elle n'est pas populaire auprès du comité. La priorité est donnée aux « Profils », un projet qui vise aussi à améliorer la sécurité du langage C++, mais sans s'inspirer du modèle de Rust.

Et si le problème de C++, c'était ce comité en lui-même. Il est certes composés de personnes ayant un talent exceptionnel, mais aussi un égo qui me semble surdimensionné. Ils sont de plus beaucoup trop nombreux que pour s'accorder. Un modèle de "gérance" à la "Python", où bien que s'appuyant sur des propositions venant d'autres personnes, le développeur initial du projet "tranche" pour une solution où une autre. Le problème avec un comité trop grand, c'est que chacun "pousse" son "avis", et des avis "différents" sont acceptés, même si le lien entre ces derniers n'est pas forcément fluide.

Cela étant dit, le modèle de Rust, bien que "satisfaisant" et "fait le taf", n'est pas la meilleur réponse. Le code Rust + ces mécanismes de protections mémoire, rendent (selon moi), la lisibilité du code "difficile". J'ai déjà expliqué pourquoi je pense cela auparavant ou dans une autre discussion. Je développe actuellement un langage et son compilateur, et la manière dont la "mémoire" est sécurisée est "naturelle". Je ne prétend pas que je ne devrais pas faire "marche arrière", mais pour le moment, ma solution est simple et "non-intrusive", car ma priorité numéro 1 reste la "lisibilité du code". Ni le langage, ni le compilateur ne sont terminés, mais plus j'avance, plus j'ai "confiance" en cette solution... L'avenir me contredira peut-être. Je reste très humble face à cette problématique. Et je n'ai pas la prétention que mon petit langage entre dans la "cours des grands", il restera "confidentiel" et aura (éventuellement) une audience réduite, car il fait partie d'un projet plus large, que je pourrais (ou pas) mener à son terme.

Cela dit, les Profils sont également controversés, certains se plaignant, par exemple, que « les Profils ne ressemblent à aucune solution établie qui fonctionne, n'ont pas d'implémentation et n'ont pas été intégrés à la norme C++ 26 au début de l'année, le comité ayant préféré demander un autre livre blanc à ce sujet ». Sean Baxter ne pense pas que les Profils permettront d'atteindre cet objectif. « J'aurais mis en place des Profils s'ils avaient une chance de fonctionner », a-t-il déclaré. Il a ajouté que « toute la bibliothèque standard est dangereuse ». « J'ai proposé une std2 rigoureusement sécurisée, mais elle a été rejetée ». La controverse autour de la manière de rendre le C++ plus sûr pourrait signifier qu'il vaut mieux se tourner vers un autre langage, qu'il s'agisse de Rust ou d'un autre langage.

Oui, le C++ se tire une "nouvelle" balle dans le pied. A force, c'est normal qu'il perde pied...

Les Profils semblent moins radicaux et plus faciles à adopter, un C++ plus sûr par défaut sans imposer le modèle Rust qui vise à s'attaquer aux pièges les plus courants du C++. La principale objection est évidente : on pourrait dire que les Profils imposent moins de restrictions que ce que Safe C++ visait à fournir.

Quel est votre avis sur le sujet ?

Perso, je pense que le C++ ne devra sa survie que grâce à sa base de code immense. Sa syntaxe est déjà devenue imbuvable (c'est mon avis), alors ajouter encore quoique ce soit ne le rendra pas plus "lisible". Pour la même raison, je pense que Rust prendra le même chemin, malheureusement.

Peut-être qu'une "troisième" voix s'imposera, qui sait...

BàV et Peace & Love.

[RenarddeFeu]

Même remarque que sous l'article Rust. Au final les utilisateurs seront le juge de paix. Ils choisiront leur langage ainsi que les fonctionnalités qu'ils utilisent ou non.

À mon avis, un nouveau langage totalement interopérable avec le C++ sans passer par les appels en C, et avec une syntaxe similaire, me semble plus prometteur qu'un Safe C++ ou des Profils.

[freesket]

Safe C++ de Sean Baxter est basée sur le modèle de Rust, ce qui implique en soit d'obtenir un code parfaitement sécurisé car il y a une séparation pure des méthodes "safe" et "unsafe". Et donc, pour passer à un mode "sécurisé" il faut refaire le code complètement...

Les profils sont plus basés sur l'implémentation directe dans le compilateur des outils d'analyses statique (basés eux-même sur le CppCoreGuidelines) déjà existants (contrairement à ce que dit Baxter d'ailleurs) que l'on trouve dans MSVC, Clang (et autres) et certains ajouts au runtime.
Note this good summary by David Chisnall (ancien de chez Microsoft Research, chercheur à l'University de Cambridge et architecte système chez SCI Semiconductor) in a January 2024 FreeBSD mailing list post:
"Between modern C++ with static analysers and Rust, there was a small safety delta. The recommendation [to prefer Rust for new projects] was primarily based on a human- factors decision: it’s far easier to prevent people from committing code that doesn’t compile than it is to prevent them from committing code that raises static analysis warnings. If a project isn’t doing pre-merge static analysis, it’s basically impossible."

Pour vous faire une idée des profils initiaux lisez le papier blanc P3081R2.
Le but du comité est de réduire drastiquement (mais pas complétement au début tout du moins) les plus gros problèmes de sécurités sans avoir à modifier (peu ou pas beaucoup) le code existant... Pour ce qui est du "type", "init", "bound" safety il y a beaucoup d'efforts de faits.

Reste le "lifetime safety" qui pour le coup n'est pas au niveau.
D'ailleurs Baxter le souligne bien et montre bien que ce "profil" n'est pas suffisant... Et il a raison. L'implémentation la plus avancée est celle fournie dans MSVC et elle n'est pas parfaite. D'ailleurs le "lifetime safety complet" (P1179R1) doit faire l'objet d'une TS pour avoir le retour des différentes implémentations.

Enfin le modèle de Baxter apporte, comme pour Rust, le "thread safety" qui... Pour le moment n'est pas traité par les profils.

Bref, les profils sont là pour une adoption rapide et une sécurisation (imparfaite mais significative) du code existant ou nouveau. J'espère que le comité va voter pour son adoption dans C++26 sans passer par une TS... Cela serait déjà un très bel ajout pour la sécurisation du code C++.