Discussion :

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

[Uther]

Je vois beaucoup de procès en wokisme contre Rust basés sur beaucoup de fantasmes et un seul fait : le code de conduite de Rust qui dit en gros d'éviter de discriminer des gens dans les canaux de communication officiels de la communauté et invite a garder les débats dépassionnés. Certes c'est un grave problème si l'on considère que harasser les minorités est un droit fondamental. Mais pour moi ce n'est pas du tout woke (si tant est que ce mot ait un sens), c'est le respect minimal que l'on est en droit d'attendre dans un groupe de travail. En dehors de la règle de non discrimination, Rust ne porte pas de projet politique particulier. je sais qu'il y a au moins un communiste, et conservateur revendiqués dans les équipes, mais une écrasante majorité est sans opinion affichée. Tous ces gens travaillent ensemble sans trop de difficulté, car il n'y a pas grand chose de mois politique qu'un langage de programmation.

Quand bien même Rust serait géré par des idéologistes woke, ça ne changerait absolument rien à ces capacité techniques. Un langage n'est pas un projet politique, c'est un outil qui n'a de sens que suivant la façon dont on l'utilise et c'est d'autant plus vrai pour un langage libre qui ne peut introduire de limitation d'usage. Rust est clairement utilisable pour tout. Pour citer quelque usages particulièrement woke de Rust, il y a les très nombreux projets de crypto-monnaies (les wokes adorant détruire l’environnement pour permettre une meilleure spéculation), chez Space X (Elon Musk étant un woke bien connu) ou pour du piratage pour des intérêts Russes (Poutine étant lui aussi un woke convaincu).

[OuftiBoy]

En ce moment Rust n'est pas encore enseigné dans mon école supérieur !

Si on veut maîtriser un langage, quelqu'il soit, il ne suffit pas de l'apprendre, mais le comprendre. Et la compréhension passe par la pratique, et cela demande du temps. A là sortie de n'importe qu'elle école, tu connais un peu de théorie, la syntaxe d'un où de quelques langages, mais tant que tu n'as pas "mis les mains" dans le cambouis, tu ne seras pas un bon développeur, tant que tu n'as pas été confronté à la réalité.

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 !

Ce n'est pas propre à l'informatique, mais tout change très vite aujourd'hui. Et un prof, c'est un être humain comme un autre. Pour qu'il puisse t'apprendre Rust, il faut d'abord que lui le comprenne, ce qui demande du temps, et l'envie. Les concepts propre à un langage, la bonne manière d'utiliser un langage, ça ne se fait pas via une formation de 15j. Il faut des années pour devenir un bon Développeur.

BàT et Peace & Love.

[OuftiBoy]

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.

Je ne suis pas devin, mais l'informatique à une multitudes d'applications pour des cas très différents, dans des domaines très différent. Et ces différents domaine demandent différentes compétences, différents outils.

Dans les petits systèmes embarqués, tu es souvent confronté à des µProcesseur n'ayant que que 16K de ROM et 4K de RAM. Et même encore moins bien souvent. Tu peux oublier le WebAssembly de ce cas là.

Si tu veux bien gagner ta vie, apprend le COBOL, car toute l'informatique du domaine bancaire, repose sur une immense masse de code COBOL, et que les programmeur COBOL se font rarent.

Tu dis: il y a beaucoup d'applications qui ne seront pas compiler en langage machine dans le futur. En fait, c'est déjà depuis longtemps que cela existe, Java, Python, C#, sont des langages qui, une fois compilé, génère un Byte code, puis ce Byte code est utilisé par une machine virtuelle.

Mais C/C++ eux sont compilé directement en langage machine, c'est pourquoi ils vont plus vite, parce que leur code est directement exécuté par le processeur. Et Rust aussi est compilé en code natif. C'est pour ça qu'il est "presque" aussi rapide que le C/C++.

BàT et Peace & Love.

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

[Uther]

A noter que pour des évolutions plus substantielles visant a rapprocher C++ de Rust niveau sécurité mémoire, il y a ce draft très intéressant qui est paru, il y a peu : https://safecpp.org/P3390R0.html
Mais là, on va dans des changement drastiques, je doute que ça soit pour demain et nul doute que la transition serait encore plus compliquée que celle vers le C++ moderne

[OuftiBoy]

Est ce que la perte de l'héritage multiple ne va pas poser problème ?

L'héritage multiple, ce n'est pas forcément nécessaire, ni forcément une bonne pratique. Il faut parler en terme d'interface, et toujours préférer la composition plutôt que l'héritage lorsque c'est possible.

BàT et Peace & Love.

[OuftiBoy]

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 POO n'est pas implémentée de la même manière dans tous les langages. La POO en Java est différente de la POO en Python. Tout comme la notion de Private. En python, on évite les get/set. On utilise directement la variable. Mais si cette variable se termine par 1 '_', c'est une convention marquant la variable comme étant "private". C'est une approche plus simple, plus clair et nettement moins verbeuses.

Créer un "accesseurs" pour lire une variable private n'a de sens que si un traitement doit se faire avant de retourner la valeur, tu peux le faire via des accesserus, tout comme tu peux ajouter une fonction a appeler à la place d'utiliser la variable. S'il faut un traitement sur la variable avant ou après set/get, en Java tu dois passer par ces fameux Get/Set, et si tu as un code appelant qui utilisait directement la variable, tu casses le code appelant.

En Python, la solution est plus élégante. Un utilisateur peu directement utiliser une variable, et si par la suite, il faut ajouter un traitement avant de retourner la variable, tu ajoute simplement une propriété qui permet un traitement avant de retourner la variable, et ça ne casse pas le code de l'appelant, qui lui peut continuer a utiliser la variable comme avant.

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

Je ne vois pas trop le rapport avec le tas et la pile par rapport aux accesseurs. Mais poser une telle question m'interpelle. La pile est le moyen le plus utilisé pour faire des appels de fonctions, qui au niveau assembleur deviennent des PUSH et des POP.

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