Le C++ doit être du C++

Une opinion qui est le fruit de 23 années d'expérience en C++, par David Sankel

Résumé

Au cours des dernières années, la communauté C++ a dû faire face à des situations difficiles dans les médias sociaux, à des appels à un soi-disant successeur et à des signes de réglementations de sécurité anti-C++ à venir. Tout cela vient s'ajouter au stress habituel des comités face à des conceptions concurrentes et à des difficultés de hiérarchisation des priorités. Dans une telle période, il est facile de s'attarder sur les problèmes ou d'adopter des positions férocement défensives.

Cet article tente de recadrer les récits non constructifs et d'affirmer que la véritable opportunité du comité est d'améliorer la vie des gens. Nous montrerons comment cette perspective permet d'orienter la participation, l'orientation et les responsabilités du comité.

Introduction

La communauté C++ a traversé de nombreuses épreuves au cours des dernières années. Le présent document ne tente pas de retracer cette histoire (Dieu nous en préserve !), mais reconnaît plutôt que les circonstances actuelles ont amené les membres du comité à se demander "Pourquoi sommes-nous ici ?", "La participation à la normalisation du C++ vaut-elle encore la peine ?", "Que réserve l'avenir au C++ ?", et "Où devrais-je investir mes efforts ?". Les réponses apportées aujourd'hui à ces questions définiront le C++ pour les années à venir.

Le présent document défend mon point de vue personnel et les orientations techniques qui en découlent. Mes opinions sont le fruit de 23 années d'expérience industrielle en C++ et de 8 années de participation active à des comités. Les innombrables conversations que j'ai eues avec des ingénieurs dans le cadre de ma participation à la Fondation Boost, à la Bloomberg C++ Guild, aux conférences sur le C++ et à #include<C++> y ont également contribué. Cependant, je ne prétends pas avoir toutes les réponses et je me réserve le droit de changer d'avis lorsque de nouvelles informations se présentent.

Ce document est divisé en trois parties. La première examine différentes idées concernant la mission du Comité de normalisation du C++ et affirme que la plus convaincante est d'améliorer la vie des gens. La deuxième partie aborde certains modèles sociaux et tentations qui conduisent à des décisions contre-productives. La dernière partie se concentre sur les biais techniques et examine certains des choix immédiats auxquels le comité est confronté.

Remerciements

Certains des propos que je tiens ici ont été exprimés avec plus d'éloquence dans d'autres ouvrages. Je renvoie le lecteur en particulier à Direction for ISO C++ (P2000R4) du groupe de direction et à Thriving in a Crowded and Changing World de Bjarne Stroustrup. Je citerai abondamment ces documents. How can you be so certain? (P1962R0) et Operating principles for evolving C++ (P0559R0) traitent également de sujets similaires.

Je m'en voudrais de ne pas remercier Niall Douglas, Inbal Levi, Bjarne Stroustrup et Herb Sutter pour leurs précieux commentaires qui ont permis d'améliorer considérablement ce document.

Mission

La plus grande menace

Comment pouvez-vous en être si certain ? affirme que "si nous ne sommes pas prudents, le C++ peut encore échouer". Les principes de fonctionnement pour l'évolution du C++ suggèrent des principes "afin de maintenir le C++ en vie, en bonne santé et en progrès". Ces déclarations, qui représentent un point de vue plus large de la communauté, impliquent que le C++ est une entité qui a acquis quelque chose de précieux qui peut être perdu. Qu'est-ce que cela signifie exactement ?

Il est facile de constater que le C++ est un langage de programmation polyvalent qui convient - son adoption par des millions de personnes en est la preuve. Les ingénieurs le maîtrisent en un temps raisonnable et l'utilisent pour résoudre leurs problèmes. C'est l'utilité du C++ qui compte.

Nombreux sont ceux qui pensent que d'autres langages de programmation "menacent" le C++ ou ont le potentiel de lui "enlever" ce qu'il possède. Un examen plus approfondi révèle que la présence d'un nouvel outil ne rend pas un outil existant moins performant, mais potentiellement plus performant.

Qu'en est-il de la législation réglementaire ? Elle ne peut pas plus modifier les capacités du C++ que celles de mon marteau. Le C++ fait ce qu'il fait et est utile là où il est utilisé. Contrairement à mon marteau, cependant, il existe une entité qui a le pouvoir de dégrader l'aptitude du C++ : le comité de normalisation du C++.

Le moyen le plus sûr de rendre une norme inutile est de dire oui à tout. Il est facile de comprendre pourquoi : la normalisation d'un fouillis complexe d'idées incohérentes devient rapidement une "folie au point de mettre en péril l'avenir du C++"[1]. Si mon marteau est remplacé par un gadget complexe nécessitant des milliers de pages d'instructions, il ne m'est plus utile. Pourtant, c'est exactement ce qui se passe avec le C++.

Si la plus grande menace qui pèse sur le C++ est le comité de normalisation, la question se pose alors de savoir comment atténuer le risque et l'aligner sur un bien plus grand.

Mission

Un organisme composé de centaines d'individus ne peut fonctionner sans une mission unificatrice. Il existe de nombreuses idées sur ce que devrait être la mission du WG21, mais voici quelques exemples qui méritent d'être pris en compte :

1. Faire du C++ le meilleur langage au monde.
2. Faire du C++ le seul langage utilisé.
3. Faire du C++ le langage le plus populaire.

Les idées de "meilleur", "unique" ou "plus populaire" langage sont discutables, mais leur impact est plus préoccupant. Tout d'abord, cette perspective conduit à une aversion pour les autres langages, à la fois par fierté et par crainte que ces autres langages soient "meilleurs". Considérons, par exemple, que 40 % des développeurs C++ veulent utiliser Rust et que 22 % le font déjà ; ignorer Rust, c'est ignorer nos utilisateurs[2]. Deuxièmement, positionner le C++ comme le "meilleur" langage conduit à greffer des caractéristiques d'autres langages au détriment de la complexité et de la cohérence. Enfin, beaucoup d'énergie est dépensée en arguments inutiles affirmant que les avantages des langages "concurrents" sont exagérés et que les inconvénients du C++ sont exagérés.

Nous avons besoin d'une mission plus constructive et je pense qu'il y en a une : améliorer la vie des gens. Lorsque Range-based for loop a été introduite dans les compilateurs, des millions de développeurs ont souri et se sont dit "Ah, c'est bien". Il se peut même que cela leur ait permis de passer une bonne journée. C'est le genre de bienfait massif que le WG21 peut contrôler et s'y aligner est incroyablement gratifiant.

Un état d'esprit altruiste élimine l'idée de "concurrent". Est-ce qu'Habitat for Humanity s'ennuierait si le Peace Corps arrivait en premier dans une région en détresse ? Bien sûr que non ! Ils se réjouiraient de l'arrivée de l'aide. Il devrait en être de même pour nous lorsque nos utilisateurs résolvent leur problème à l'aide d'un outil différent. Les autres communautés linguistiques qui aident nos utilisateurs sont nos alliés. Nous ne devons pas l'oublier. Les guerres de territoire ne servent pas les intérêts de nos utilisateurs.

L'aspect social

Certains schémas de pensée vont à l'encontre d'une mission visant à améliorer la vie des gens. Il est important d'en être conscient, car ils ne manqueront pas de surgir.

Le C++ en tant qu'identité personnelle et de groupe

L'une des premières questions que se posent les programmeurs dans un contexte social est : "Dans quel langage programmez-vous ? Cette question ouvre souvent la voie à des stéréotypes regrettables. "Oh, un programmeur Java qui écrit du code lent". "Oh, un programmeur Python qui ne sait pas programmer dans un "vrai" langage". "Oh, un programmeur Go qui ...". Lorsque nous pensons au C++, nous pouvons être fiers de maîtriser un langage difficile, d'être capables d'écrire des codes très performants et d'avoir une relation avec les plus grands travaux C++ du monde.

Si l'identification au C++ en tant que source de grandeur et de raison d'être présente des avantages, elle a un coût. Tout d'abord, comme il s'agit avant tout d'un transfert émotionnel, la raison s'en trouve obscurcie. Lors de ma première réunion en commission, on m'a conseillé d'éviter de mentionner la programmation fonctionnelle, de peur que les gens ne rejettent mes arguments dès qu'ils entendent ces mots. Deuxièmement, une identification profonde avec le C++ peut créer des craintes profondes que le C++ devienne un langage "hérité" qui rende obsolète l'ensemble des compétences (et même la personne !).

Je mentionne ces éléments parce qu'ils compromettent souvent la mission de normalisation visant à améliorer la vie des gens. Nous devons évaluer le monde des langages de programmation sans que le tribalisme ne nous incite à ignorer ou à surcompenser les problèmes.

Rhétorique contre-productive

On écrit et on parle souvent du C++ comme s'il s'agissait d'un être vivant. Des mots comme "fatal"[3], "fail"[4], "dead"[5], et "death"[6] sont courants dans notre littérature. Lorsque nous imaginons le C++ comme un être vivant, nous associons naturellement des ressources finies (utilisateurs actifs), la concurrence (d'autres langages) et la mort (obsolescence). Ce raisonnement est fondamentalement erroné. Le C++ n'est pas vivant, ne peut pas mourir et n'est en concurrence avec rien. C'est simplement un outil qui est parfois utile.

Nous devons nous éloigner de ce mode de pensée. Combinée au transfert évoqué précédemment, elle génère de la peur et encourage l'idée d'ennemis. Le manque actuel de coopération et de crédit entre les différentes communautés linguistiques est tout à fait regrettable. Dans le pire des cas, les gens sont rabaissés à cause du langage de programmation auquel ils s'associent.

Souvenons-nous que a) les langages ne se battent pas, ce sont les gens qui se battent, b) dénigrer les autres langages n'améliore pas la vie des gens, et c) l'éternité du C++ n'est pas notre objectif.

La normalisation comme opportunité personnelle ou comme gérance

Lorsque l'on rejoint le comité pour la première fois, il est facile de voir la participation comme une opportunité personnelle d'acquérir de l'expertise en C++, de côtoyer des célébrités et, pire encore, de laisser une trace dans le monde en faisant accepter une proposition. Bien que toutes ces choses se produisent effectivement, il y a quelque chose de beaucoup plus important en jeu ici.

Le groupe de direction prévient que "nous écrivons une norme sur laquelle des millions de programmeurs s'appuieront pendant des décennies, un peu d'humilité s'impose"[7] Il ne s'agit pas d'un privilège qui se mérite et aucun d'entre nous n'est vraiment qualifié pour prendre ces décisions, mais nous sommes là. Notre lourde responsabilité l'emporte sur les opportunités personnelles.

Qu'est-ce que cette responsabilité implique ? Cela signifie qu'il faut rejeter les propositions qui n'ont pas de valeur ajoutée compréhensible. Cela signifie qu'il faut résister à la pression sociale lorsque l'on est contre quelque chose. Cela signifie qu'il faut se forger une opinion éclairée en lisant le document, en testant la fonctionnalité et en collaborant avec d'autres. Cela signifie qu'il ne faut dire "oui" que lorsque le risque est minimal. Par-dessus tout, c'est une question d'intendance : vous êtes le gardien de quelque chose qui vous dépasse.

Si vous devez rédiger une proposition, gagnez du temps et évitez les frustrations en demandant l'aide de concepteurs expérimentés et d'experts en rédaction. Ils veulent vous aider ! Demandez-vous également si le problème que vous résolvez justifie la complexité et le risque supplémentaires. Le C++ est un langage qui "essaie d'en faire trop, trop vite"[8] et qui doit "devenir plus sobre et plus sélectif"[9].

L'aspect technique

Tout aussi importantes que nos tendances sociales sont les tendances techniques qui vont à notre encontre. Cette section présente plusieurs anti-modèles, dont aucun n'est nouveau [10].

Néophilie

Bjarne a déclaré succinctement que "l'enthousiasme favorise la nouveauté"[11]. Les innovations technologiques et les modes suivent une courbe de battage familière [12] qui commence par un pic d'attentes exagérées. Nous risquons de nous laisser emporter par l'enthousiasme et de standardiser des fonctionnalités qui, rétrospectivement, ne tiennent pas leurs promesses, s'intègrent mal au reste du langage et augmentent les coûts d'apprentissage.

Prenons l'exemple des traits Rust, qui résolvent des problèmes similaires à ceux des concepts C++. La sémantique explicite des traits offre plusieurs avantages, y compris des génériques à vérification de type séparée. Devrions-nous ajouter les traits au C++ ? Si nous le faisons, nous nous retrouverons avec deux façons de résoudre le même problème, avec des millions de lignes de code utilisant l'ancienne méthode. De plus, la plupart des développeurs devront être familiers avec les deux pour être efficaces dans une grande base de code existante, ce qui aggravera les coûts d'apprentissage du C++.

Ce n'est pas parce qu'un autre langage a quelque chose de potentiellement meilleur que le C++ que nous devons l'intégrer. "Suivre les Jones" n'est pas un bon service. Nous devrions nous demander comment les non-experts, qui constituent la plupart de nos utilisateurs, réagiront lorsqu'ils verront une fonctionnalité pour la première fois dans le code de quelqu'un d'autre. Il s'agit souvent d'une frustration liée au fait de devoir passer du temps à apprendre quelque chose qui ne présente qu'un avantage marginal par rapport à ce qu'il remplace.

Fonctionnalités et priorité aux experts

Le comité C++, principalement composé d'experts, laisse les programmeurs moyens "sérieusement sous-représentés"[13]. Cela "oriente le comité vers la légistique du langage, les fonctionnalités avancées et les questions d'implémentation, plutôt que de répondre directement aux besoins de la masse des développeurs C++, que de nombreux membres du comité ne connaissent qu'indirectement"[14].

Le temps passé sur les fonctionnalités expertes gâche des opportunités d'améliorer la vie à grande échelle. Lorsque nous classons une proposition par ordre de priorité, nous devrions nous demander si elle résout un problème pour les experts ou pour le développeur moyen. Si c'est le premier cas, nous devrions sérieusement envisager de passer à autre chose.

Le déséquilibre entre les experts se traduit également par des solutions trop compliquées qui requièrent des compétences avancées pour des tâches simples. Pensez aux obstacles à franchir pour faire fonctionner std::print avec un type personnalisé par rapport aux anciens opérateurs de flux. Il est trop facile pour les experts de perdre le contact avec les novices et les ingénieurs professionnels qui ne passent pas leur temps libre à apprendre les complexités avancées du C++, surtout lorsqu'ils sont entourés d'autres experts.

L'une des choses les plus utiles que peuvent faire les membres des comités est de discuter des propositions avec les ingénieurs d'application. "Est-ce quelque chose que vous utiliseriez ?". "Est-ce ergonomique ? "Est-ce difficile à apprendre ?". "Cela vaut-il la peine d'ajouter un chapitre au livre sur le C++ ? Ce type de retour d'information devrait peser plus lourd que les théories abstraites sur ce qu'un développeur idéal devrait vouloir.

La complexité

Le groupe de direction considère que "le C++ est en danger de perdre sa cohérence à cause de propositions basées sur des philosophies de conception différentes et parfois mutuellement contradictoires et sur des goûts stylistiques différents" [15]. Bjarne pense que cela est dû à une combinaison de la croissance du comité, de l'arrivée de nouvelles personnes, de la spécialisation des membres et d'une diminution de la connaissance de l'histoire du C++ parmi les membres[16].

Les changements qui réduisent la cohérence augmentent la complexité, ce qui accroît les coûts de formation. Il est beaucoup plus difficile d'embaucher des développeurs C++ que d'autres développeurs, non pas en raison de la demande, mais parce que la barrière à l'entrée est trop élevée. Moins de personnes veulent apprendre le C++ et moins d'écoles veulent l'enseigner. L'une des principales façons dont nous pouvons améliorer la vie des gens est d'aider nos utilisateurs à trouver des collègues.

Le groupe de direction se souvient qu'Alex Stepanov a sauvé le C++ du désastre en apportant de la consistance et de la cohérence à la bibliothèque standard[17], et pourtant nous débattons activement de la rupture de ces mêmes règles pour un ajout de bibliothèque relativement niché. Nous avons récemment remplacé un simple modèle std::function par pas moins de trois alternatives : std::copyable_function, std::function_ref, et std::move_only_function. Cela ne nous aide pas à résoudre nos problèmes de complexité !

Je suis d'accord avec le groupe de conception pour dire que nous devons "viser la cohérence"[18]. Voici trois suggestions concrètes pour y parvenir :

1. Limiter la tendance à centrer les discussions sur les propositions sur un domaine problématique étroit en demandant comment il s'intègre dans l'ensemble de l'offre C++. "Est-ce que cela correspond au style commun du C++ ? "Est-ce que cela augmente la barrière à l'entrée du C++ ? Quel serait l'impact sur l'hypothétique "livre C++" ?
2. Encourager les groupes d'étude à obtenir un retour d'information précoce de la part des groupes d'évolution (EWG et LEWG) sur l'opportunité des fonctionnalités[19] Les groupes d'évolution sont responsables de la prise en compte de la situation dans son ensemble. Le fait d'obtenir ce retour d'information avant une itération intensive de la commission d'études peut éviter que des caractéristiques indésirables ne prennent de l'ampleur, ce qui serait difficile à arrêter.
3. Surmonter la réticence à dire "Je ne pense pas que ceci ait sa place en C++". Nous ne rendons pas service aux auteurs en fournissant un retour d'amélioration sur des propositions qui ne sont finalement pas souhaitables.

Les problèmes de niche nécessitent plus qu'un effort de niche

Au sein du comité, nous consacrons souvent du temps à des choses qui n'intéressent qu'un petit nombre de personnes. Il est difficile de dire "non" lorsque quelqu'un, quelque part, en bénéficierait. Nous avons également tendance à nous déconnecter mentalement au cours de ces discussions, ce qui fait que les propositions ne bénéficient pas d'une rigueur appropriée.

Lorsque nous tombons dans ces pièges, 1) nous privons le plus grand nombre d'utilisateurs du temps consacré à des propositions susceptibles d'améliorer leur vie, 2) nous augmentons inutilement la complexité du langage et de la bibliothèque, et 3) nous encourageons les propositions de niche.

Pour résoudre ces problèmes, il suffit de dire "non" plus souvent et, si nécessaire, à plusieurs reprises. Les corrections de bogues mises à part, le comité devrait consacrer son temps à un nombre plus restreint de propositions ayant un impact plus important. Les efforts consacrés à la rédaction d'articles visant à résoudre les bêtes noires du C++ sont mieux utilisés pour rédiger des analyses et des rapports d'expérience sur des propositions à plus fort impact. Nous devrions faire plus pour reconnaître ce travail.

Aller de l'avant

Cette section examine la sécurité de la mémoire et une révision majeure du C++ à la lumière des principes de ce document.

Sécurité de la mémoire

Les documents officiels discutant de la législation contre le C++ en raison de son "manque de sécurité de la mémoire" ont suscité l'émoi de la communauté. Nous avons vu de gigantesques fils d'e-mails, un nouveau groupe d'étude dédié à la sécurité, et de nombreux exposés lors de conférences sur le C++. Ce qui est beaucoup moins répandu, c'est la demande des utilisateurs moyens de C++ pour des fonctionnalités de sécurité de la mémoire ; ils sont beaucoup plus préoccupés par la vitesse de compilation. Lorsque la plupart des développeurs C++ n'ont pas adopté des outils tels que Coverity et les vérificateurs de lignes directrices du noyau C++, il est difficile de prétendre que les fonctions de sécurité de la mémoire améliorent sensiblement leur vie, du moins de leur point de vue.

Lorsque la sécurité de la mémoire est une préoccupation sérieuse, nous voyons l'adoption de Rust pour les composants critiques. Pourtant, même ces développeurs ne demandent guère de fonctions de sécurité C++. Leur problème est déjà résolu.

Le groupe de direction affirme qu'"aucun langage ne peut être tout pour tout le monde"[20] et je suis tout à fait d'accord. Rust et d'autres langages répondent avec succès aux besoins des ingénieurs en matière de garanties de sécurité de la mémoire dans les composants critiques. Ce n'est pas un espace dans lequel nos utilisateurs nous demandent d'aller, et ce faisant, nous risquons à la fois l'échec et, oui, encore plus de complexité.

Révision majeure du C++

Au cours des deux dernières années, il est devenu à la mode de parler des "successeurs du C++", ce qui va de changements syntaxiques spectaculaires au remplacement du comité C++ par une autre organisation. Quelle devrait être la réponse du comité à ce phénomène ?

Pour les groupes qui tentent de créer un nouveau langage en dehors du comité, je pense que notre réponse devrait être un soutien. Si ces initiatives ne créent pas de confusion ou ne nuisent pas à nos utilisateurs, elles partagent notre objectif d'améliorer la vie des gens. Lorsqu'elles réussissent, c'est une bonne chose. Même si elles échouent, les idées qu'elles génèrent peuvent finalement aider nos utilisateurs.

Qu'en est-il de l'option de changer radicalement le visage du C++ dans le contexte du WG21 ? Un C++ 2.0, peut-être ? Si vous demandez à un développeur C++ typique comment nous pouvons améliorer sa vie, une nouvelle syntaxe moderne et élégante ne sera pas en tête de sa liste. Oui, les template et les typename sont fastidieux à lire et à taper, mais c'est ce qu'ils connaissent et ils préfèrent qu'on n'y touche pas. Il ne s'agit pas seulement d'une réticence au changement : nos utilisateurs veulent de la cohérence dans leur base de code C++ autant que nous voulons de la cohérence dans la norme.

Si un successeur au C++ devait un jour voir le jour, nos utilisateurs voudraient qu'il soit le meilleur possible. La composition du comité n'a pas de qualité magique qui le rendrait plus apte à construire un successeur que n'importe quelle autre entité. L'inertie liée à l'adoption de C++ 1.0 pourrait même conduire à l'adoption de C++ 2.0 alors que d'autres tentatives de successeur sont plus adaptées. Ce ne serait pas une bonne chose pour nos utilisateurs.

En résumé, la plus grande opportunité pour le comité C++ d'améliorer la vie des gens est de se concentrer sur le C++ tel qu'il est aujourd'hui pour mieux nous servir dans quelques années sous les contraintes de la compatibilité. Laissons les projets spéculatifs de succession à des entités externes. Nous sommes déjà suffisamment distraits.

Que devrions-nous faire ?

J'ai beaucoup parlé de ce que nous ne devrions pas faire. C'est intentionnel : nous devons en faire moins. Cependant, je ne veux pas donner l'impression que nous devrions refuser toutes les propositions. Il existe de nombreuses possibilités d'améliorer la vie de nos utilisateurs par le biais de propositions. Voici quelques exemples concrets :

• Un hachage plus rapide et des combinateurs de hachage. Les interfaces "hash map" et "hash set" de la bibliothèque standard datent maintenant de plusieurs dizaines d'années. Au cours de cette période, nous avons assisté à une explosion de leur utilité et à de nombreuses avancées algorithmiques, avancées qui nécessitent un changement d'interface. En ajoutant des structures de données de hachage plus modernes à la norme, nous pouvons améliorer considérablement les performances et l'impact environnemental du code nouvellement écrit. Nos utilisateurs ont aussi désespérément besoin d'un moyen normalisé de combiner les hachages dans leurs propres fonctions de hachage.
• Analyse JSON. Une bibliothèque d'analyse JSON et de sérialisation simple, ergonomique et normalisée évitera à de nombreux utilisateurs de rechercher des bibliothèques ou, pire, d'écrire des formats personnalisés. L'objectif n'est pas d'être l'analyseur JSON le plus rapide au monde.
• Analyse de la ligne de commande. Une bibliothèque simple et standardisée pour l'analyse de la ligne de commande améliorera également la vie des 99% d'utilisateurs en remplaçant l'analyse argv[1] courante dans les petites applications.

Il y a beaucoup d'autres idées comme celles-ci. L'objectif est de donner au plus grand nombre la réaction "ah, c'est bien".

Conclusion

Ce document plaide en faveur d'une mission de normalisation du C++ : améliorer la vie des gens. Il a également identifié les biais sociaux et techniques qui entravent cette mission. Enfin, il a pris en compte les principales discussions en cours au sein du WG21 et a suggéré des idées pour les travaux futurs.

En fin de compte, lorsque je dis que "le C++ doit être le C++", je veux dire que le C++ est un langage utile pour la société. je veux dire que le C++ est un outil utile tel qu'il est - des changements radicaux ne sont pas utiles. Pour éviter qu'il ne devienne ce qu'il n'est pas, nous devons dire "non" plus souvent, reconnaître nos préjugés et, surtout, donner la priorité à nos utilisateurs.

References

“2023 Developer Survey.” Stack Overflow, 2023, https://survey.stackoverflow.co/2023/.

Hinnant, Howard et al. “Direction for ISO C++.” 15 October 2022, https://wg21.link/P2000R4.

Stroustrup, Bjarne. “How can you be so certain?” 18 November 2019, https://wg21.link/P1962R0.

Stroustrup, Bjarne. “Remember the Vasa!” 6 March 2018, https://wg21.link/P0977R0.

Stroustrup, Bjarne. “Thriving in a Crowded and Changing World: C++ 2006-2020.” Proc. ACM Program. Lang., vol. 4, HOPL, June 2020, Article 70, pp. 1-167, https://doi.org/10.1145/3386320.

van Winkel, J.C. et al. “Operating principles for evolving C++” 31 Janurary 2017, https://wg21.link/P0559R0.

1. Remember the Vasa! (P0977R0)
2. The Stack Overflow 2023 survey had 89,184 respondents. 19,634 indicated they did "extensive development work" C++ over the past year and 4,269 claimed extensive development work in both Rust and C++ over the past year. Of those who used C++, 7,918 indicated a desire to work in Rust over the next year.
3. Direction for ISO C++ (P2000R4)
4. How can you be so certain (P1962R0)
5. Operating principles for evolving C++ (P0559R0)
6. ibid.
7. Direction for ISO C++ (P2000R4)
8. How can you be so certain (P1962R0)
9. ibid.
10. See Thriving in a Crowded and Changing World and Direction for ISO C++ (P2000R4)
11. Thriving in a Crowded and Changing World
12. https://en.wikipedia.org/wiki/Gartner_hype_cycle
13. Direction for ISO C++ (P2000R4)
14. Thriving in a Crowded and Changing World
15. Direction for ISO C++ (P2000R4)
16. Thriving in a Crowded and Changing World
17. Direction for ISO C++ (P2000R4)
18. ibid.
19. Credit to Niall Douglas for this idea
20. Direction for ISO C++ (P2000R4)

Source : "C++ Should Be C++" par David Sankel

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

La norme C++23 supprime la prise en charge du Garbage Collection par Sandor Dargo, développeur C++

Livrer un C++ sûr, par Bjarne Stroustrup au CppCon 2023. Sa présentation expose une approche basée sur les profils de sécurité pour relever ces défis

Bjarne Stroustrup, 72 ans, créateur du langage C++, partage ses conseils de vie et a également raconté comment il est devenu programmeur par erreur