Discussion :

[Jade Emy]

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.

Bjarne Stroustrup a présenté des « profils » renforçant les lignes directrices pour la sécurité des ressources et des types de C++. Ces profils sont un moyens de s'assurer que le code soit contemporain, plutôt que de s'appuyer sur des techniques dépassées, peu sûres et difficiles à maintenir.

Le C++ est un langage de programmation général de haut niveau. Publié pour la première fois en 1985 en tant qu'extension du langage de programmation C, il s'est considérablement développé au fil du temps. Depuis 1997, le C++ possède des caractéristiques orientées objet, génériques et fonctionnelles, ainsi que des fonctions de manipulation de la mémoire de bas niveau pour des systèmes tels que les micro-ordinateurs ou pour créer des systèmes d'exploitation tels que Linux ou Windows. Il est généralement implémenté en tant que langage compilé, et de nombreux fournisseurs proposent des compilateurs C++.

Le C++ a été créé par l'informaticien danois Bjarne Stroustrup. Il a notamment dirigé le département de recherche sur la programmation à grande échelle aux Bell Labs, a été professeur d'informatique à l'université Texas A&M et a passé plus d'une décennie chez Morgan Stanley tout en étant professeur invité à l'université Columbia. Depuis 2022, il est professeur titulaire à Columbia.

Récemment, Bjarne Stroustrup a présenté des « profils » renforçant les lignes directrices pour la sécurité des ressources et des types de C++. "Cela fait maintenant plus de 45 ans que le C++ a été conçu", écrit Bjarne Stroustrup dans un article publié cette semaine dans Communications of the ACM. Il se plaint que de nombreux développeurs "utilisent le C++ comme s'il s'agissait encore du millénaire précédent", dans un article intitulé 21st Century C++ qui promet "les concepts clés sur lesquels des logiciels C++ performants, sûrs et flexibles peuvent être construits : la gestion des ressources, la gestion de la durée de vie, la gestion des erreurs, la modularité et la programmation générique...".

Bjarne Stoustrup présente des moyens de s'assurer que le code soit contemporain, plutôt que de s'appuyer sur des techniques dépassées, peu sûres et difficiles à maintenir : les lignes directrices et les profils.

Pour aider les développeurs à se concentrer sur l'utilisation efficace du C++ contemporain et à éviter les « coins sombres » obsolètes du langage, des ensembles de lignes directrices ont été élaborés. Je me concentre ici sur les lignes directrices du C++ Core que je considère comme les plus ambitieuses... Mon objectif principal est une utilisation de la norme ISO C++ sans danger pour les types et les ressources. En d'autres termes :

- Chaque objet est exclusivement utilisé conformément à sa définition
- Aucune ressource n'est perdue.

Cela englobe ce que les gens appellent la sécurité de la mémoire et bien plus encore. Il ne s'agit pas d'un nouvel objectif pour le C++. Il est évident qu'il ne peut pas être atteint pour chaque utilisation du C++, mais nous avons maintenant des années d'expérience montrant que c'est possible pour le code moderne, bien que jusqu'à présent l'application ait été incomplète... Lorsque l'on pense au C++, il est important de se rappeler que le C++ n'est pas seulement un langage, mais qu'il fait partie d'un écosystème composé d'implémentations, de bibliothèques, d'outils, d'enseignement, et plus encore.

Le WG21 (et d'autres) travaille sur des « profils » pour mettre en œuvre des lignes directrices (bien qu'ils ne soient "pas encore disponibles, à l'exception de versions expérimentales et partielles"). Mais Stroustrup annonce que les directives de base du C++ "utilisent une stratégie connue sous le nom de sous-ensemble de sous-ensemble".

Premièrement : étendre le langage avec quelques abstractions de bibliothèque : utiliser des parties de la bibliothèque standard et ajouter une minuscule bibliothèque pour rendre l'utilisation des directives pratique et efficace (la bibliothèque de soutien des directives, GSL).
Ensuite : sous-ensemble : interdire l'utilisation de fonctionnalités de bas niveau, inefficaces et sujettes aux erreurs.

Ce que nous obtenons, c'est du "C++ sous stéroïdes" : Quelque chose de simple, sûr, flexible et rapide, plutôt qu'un sous-ensemble appauvri ou quelque chose qui repose sur une vérification massive au moment de l'exécution. Nous ne créons pas non plus un langage avec des caractéristiques nouvelles et/ou incompatibles. Le résultat est 100% ISO standard C++. Les fonctionnalités de bas niveau, désordonnées et dangereuses, peuvent toujours être activées et utilisées en cas de besoin.

Stroustrup écrit que les directives de base du C++ se concentrent sur des règles "dont nous espérons que tout le monde pourra éventuellement bénéficier".

• Pas de variables non initialisées
• Pas de violation de plage ou de nullptr
• Pas de fuites de ressources
• Pas de pointeurs pendants
• Pas de violation de type
• Pas d'invalidation

Pour rappel, Bjarne Stroustrup, créateur du langage C++, a 74 ans. Il avait raconté qu'il est devenu programmeur par erreur, en se trompant de mot au moment de choisir ce qu'il allait étudier après ses examens de fin d'études secondaires. Stroustrup pensait s'inscrire à un cours de mathématiques appliquées, qui s'est avéré être un cours d'informatique. Maintenant, il est l'un des piliers du langage C++.

Source : Article 21st Century C++

Et vous ?

Pensez-vous que ses conseils sont crédibles ou pertinents ?
Quel est votre avis sur le sujet ?

Voir aussi :

Bjarne Stroustrup publie un article dans lequel il explique comment C++ a réussi à s'épanouir, dans un monde surpeuplé de langages et changeant de 2006 à 2020

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

Les deux factions du C++ : la communauté est divisée entre ceux qui souhaitent un C++ moderne avec un meilleur outillage intégré et ceux qui veulent conserver le langage hérité

[Patrick Ruiz]

Le créateur de C++ appelle à l'aide de la communauté du langage pour le défendre contre de graves attaques
D’agences de cybersécurité qui militent pour un passage à des langages plus sécurisés comme le Rust

Bjarne Stroustrup, créateur du langage C++, appelle la communauté C++ pour qu'elle défende ce langage de programmation. Ce dernier est sous le feu des critiques des agences de cybersécurité et des experts techniques ces dernières années en raison de ses lacunes en matière de sécurité de la mémoire. L’initiative du créateur du langage C++ se fait dans un contexte d’urgence étant donné l’appel du CISA à l’abandon du C++ d’ici à 2026.

« Il ne s'agit manifestement pas d'une note technique traditionnelle proposant un nouveau langage ou une nouvelle fonctionnalité de bibliothèque. Il s'agit d'un appel à une action urgente, en partie en réponse à des attaques graves et sans précédent contre le C++. Je pense que le WG21 doit faire quelque chose de significatif et être perçu comme tel. Profiles est un cadre qui peut le faire », déclare-t-il dans le cadre de la présentation de nouvelles lignes directrices pour la sécurité des ressources et des types.

« Comme je l'ai déjà dit, il s'agit également d'une opportunité car la sécurité des types et la sécurité des ressources (y compris la sécurité de la mémoire) ont été des objectifs clés du C++ depuis le tout début », ajoute-t-il.

Bjarne Stroustrup, créateur du C++, appelle la communauté à défendre le langage face aux critiques croissantes sur sa sécurité mémoire. Depuis plusieurs années, les experts en cybersécurité et les agences gouvernementales privilégient des alternatives comme Rust, Go ou Swift,… pic.twitter.com/musoZoUN3y

— Bruno Guglielminetti | Mon Carnet (@Guglielminetti) March 2, 2025

Certains acteurs de la filière du développement de logiciels sont d’avis qu’il faut arrêter d’initier de nouveaux projets en C++ et passer au Rust

Mark Russinovich de Microsoft recommande le langage Rust plutôt que le C ou C++. Les raisons : la parité en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. C’est en droite ligne avec cet état de choses que l’éditeur de RisingWave a abandonné son projet de SGBD cloud natif initialement développé en C++ pour le réécrire en Rust.

« Rust garantit la sécurisation de la mémoire et des threads au moment de la compilation en introduisant des règles de propriété. Il va au-delà du RAII, un mécanisme de gestion de la mémoire couramment utilisé en C++. Il présente deux avantages. Le premier est évident : une fois que le compilateur Rust a validé notre programme, nous n'aurons pas de défauts de segmentation ou de conditions de concurrence lors de l'exécution, ce qui nécessiterait des dizaines d'heures de débogage, en particulier dans une base de code hautement concurrente et principalement asynchrone. La seconde est plus subtile : le compilateur Rust restreint simplement les types de fautes, ce qui réduit les fragments de code étroitement imbriqués qui peuvent causer un tel comportement bogué. La réplication des bogues est considérablement améliorée avec l'aide de l'exécution déterministe », explique-t-il.

Linus Torvalds est d’avis que Rust est une solution d’avenir pour le noyau Linux mais certains intervenants pensent le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

Il considère la prise en charge de Rust pour le développement du noyau Linux 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 du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Néanmoins, certains intervenants comme le développeur Peter Anvin sont d’avis que C++ moderne est une meilleure alternative que Rust pour le développement du noyau Linux :

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir. »

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 devrait permettre au C++ de s’adapter et évoluer pour répondre aux besoins modernes de sécurité et de fiabilité des logiciels. 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.

Source : Bjarne

Et vous ?

Partagez-vous les avis selon lesquels les extensions Safe C++ peuvent permettre au C++ de rivaliser avec les langages modernes comme Rust en termes de sécurité ? Pourquoi ou pourquoi pas ?
Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

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

[kmedghaith]

A mon humble avis, et en tant qu'utilisateur de C++ depuis presque 20 ans, la meilleure façon de défendre le langage est de le faire évoluer en arrêtant de faire la sourde oreille à certaines demandes très raisonnables:
* Une nouvelle librairie standard, memory safe par défaut. De préférence commune à touts les compilateurs autant que possible, opensource et régulièrement mise à jour.
* Une syntaxe "C++2", sous ensemble du langage safe par défaut plus quelques additions pour le comfort. Pourquoi pas empreinter le borrow checker et les lifetimes (c'est fait dans circle)
* Un système de build et de dépendances standard et moderne

J'utilise pas mal Rust. Je comprends les gens qui veulent y passer: c'est moderne, simple et efficace. Ce n'est pas encore à parité avec le C++ concernant la programmation générique mais ça suffit pour 99% des développeurs.
Il est temps que le C++ apprenne de ses concurrents, juste comme ses concurrents ont appris du C++.

[freesket]

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

C++26 répondra à un certain nombre de points:
* La STL "hardened" par défaut (proposition rapidement adoptée car presque tous les fournisseurs de STL ont cette "option") => suppression des violations de type "bound safety".
* Le "initialisation safety"
* Les contrats (possibilité de vérifier les pré-requis et post-requis)
* Probablement la réflection statique
* Devrait apporter des profils (possiblement incomplets) pour vérifier les "type, bound, lifetime safety", inspirés de ce qu'il se fait avec les outils fournis avec clang ou cl. L'avantage c'est que ce sera directement à la compilation et non pas dans un outil séparé.
=> Conséquence, C++26 va rendre les méthodes "unsafe" (venant souvent du C) visibles (naked union, variant, enum C, NULL, pointeur de type array, for à l'ancienne, naked new/delete, malloc/free, cast douteux, les fonctions C unsafe...) et donc rendre le language plus propre et épuré pour ceux qui ne désactiverons pas la vérification à la compilation.
* Pour le petit plus (exemple not_null<T>, narrow_cast...) il faut voir du côté de la GSL (Guideline Support Library).

[Jacti]

Il fut un temps où, en plus de mon métier de concepteur/consultant, j'enseignais le C++ en entreprise à des développeurs qui connaissaient déjà d'autres langages (environ 1 cours de 5 jours/mois). Il s'agissait à l'époque de C++11. J'ai aussi audité, à l'aide de Logiscope des millions de lignes de C++ pour des applications militaires principalement (les fameux SIC et SIR). On pouvait déjà écrire du code très propre en C++ à condition d'être très discipliné et d'avoir fait une conception objet impeccable. Hélas, je me suis rendu compte que peu de développeurs comprenaient réellement et maîtrisaient la conception objet et la programmation en C++ "safe". Il me semble que les ajouts sont fait pour aider les développeurs et les guider dans des concepts qu'ils ne comprennent pas toujours jusqu'au fond des choses.
Peut-être que mon post est un peu provocateur mais c'est vraiment ce que je pense ayant pratiqué la conception objet dès le début en 1983 avec les articles de Grady Booch et le C++ dès 1993.
PS : j'ai pratiqué intensivement la métaprogrammation en C++ avec la généricité et il me semble que ce n'est qu'avec C++ qu'on arrive à faire des choses vraiment sophistiquées dans ce domaine. Rust ne lui arrive pas à la cheville.