Discussion :

[David Sankel]

Le C++ doit être du 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

Il est difficile pour un comité de se rappeler qu'un langage ne peut pas tout faire pour tout le monde. Il est encore plus difficile d'accepter qu'il ne peut pas résoudre les problèmes les plus urgents de chaque membre.

Bjarne Stroustrup, Thriving in a Crowded and Changing World

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

[prisme60]

Mon avis sur la question :

• Ne garder le C++ que pour les projets existants en attendant que le projet devienne obsolète. Essayer d'utiliser les normes plus récentes du C++ quand c'est possible (std::shared_ptr. std::jthread, std::mutex, ...)
• Ne pas commencer de nouveau projet en C++.

[23JFK]

Je fais partie de ceux qui pestent contre la litanie d'ajouts à l'utilité douteuse dont est victime le C++. A croire que le comité pense que les ++ signifie "toujours plus". A côté de ça, il y a des petits trucs dans la bibliothèque standard qui n'ont jamais été normalisée bien qu'existant depuis plus de 20 ans.

[Axel Mattauch]

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

D'accord avec ce constat, ainsi que:

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

J'aimerais en fait que les expert puissent définir un sous-ensemble de C++ suffisant pour "une majorité d'applications", et surtout suffisant pour les novices ou les programmeurs occasionnels. Selon moi - qui fais partie de cette dernière catégorie- rien n'est plus frustrant que d'avoir une multitude de façons d'écrire la même chose, ou peu s'en faut. Souvent des conséquences de compatibilité ascendantes: multiples façons d'initialiser des données ou des attributs, mots clés qui remplissent des rôles équvalents (en fait: presque, et c'est pire).

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++.
[...]
Cela signifie qu'il faut rejeter les propositions qui n'ont pas de valeur ajoutée compréhensible.
[...]
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].

Il me semble également que le comité est plus enclin à ajouter des choses qu'à en supprimer.
J'ai conscience que le suppression dure pose un problème de compatibilité avec le code existant, mais a défaut d'être impératif pourrait être incitatif (deprecated features/syntax...) . A régler avec des options de compilation.

Ce n'est pas parce qu'un autre langage a quelque chose de potentiellement meilleur que le C++ que nous devons l'intégrer. [...] 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.
[...]
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.

Je ne peux que souscrire

[archqt]

Une bibliothèque pour l'IHM serait pas mal aussi. Il y avait eu un début, des papiers comme preuve de concept, mais cela n'avait pas été plus loin, dommage.

[nikau6]

Depuis des années je le dis, alors que tout le monde semblait s'émerveiller des évolutions du C++. Ils sont en train de ruiner ce magnifique langage. Comme pour le C, l'un des points fort du C++ était sa stabilité, surtout pour un langage aussi complexe. Lire du code C++ écrit par un autre était déjà difficile, aujourd'hui ils l'ont rendu impossible.
Le C++ n'avait pas besoin d'évoluer concernant ses fonctionnalités, ou à la marge, et en prenant son temps. Par contre la bibliothèque standard avait besoin d’être étoffée, c'est sur point qu'aurait dû se concentrer toutes les avancées.

PS : Dans un processus de décision, surtout sur un sujet aussi sérieux, il y doit y avoir un chef qui à la fin approuve ou rejette une fonctionnalité, que ça plaise ou pas aux autres, sinon c'est le bordel, et le résultat final est un grand n'importe quoi. Ce chef doit avoir une vision de long terme, il doit être choisi pour ça.

Cet appel à la raison de Stroustrup est intéressant : https://www.open-std.org/jtc1/sc22/w...19/p1962r0.pdf
Mais il arrive hélas trop tard. Ils ont déjà ruiné ce langage et de manière irréversible. Son déclin est inévitable, c'est devenu un tel foutoir que maintenir des projets deviendra beaucoup trop complexe et couteux.

[Guesset]

Bonjour,

Enfin ! J'ai vu évoluer le C++ avec plus de règles, plus de paradigmes éventuellement contraires, un langage issu d'un C étique devenir verbeux, des fonctionnalités à taux d'usage très faible. Un équilibre de danseuse entre abstraction et efficacité qui multiplie les mots d'orientation de compilation.

Je l'ai beaucoup pratiqué du temps où il était le successeur naturel du C. Il apportait du plus et non du trop.

Le pire est certainement la fascination sectaire de certains pour une complexité inutile mais garante, à leur yeux, de faire partie de l'élite. C'est dommage car un langage ne peut faire marche arrière, surtout après des années. Peut être un C+/- ?

Salutations

[nikau6]

Un petit exemple du bordel qu'est devenu le c++ ( récupéré sur une conférence Cppcon 2023

)

Il existe 7 façons d'initialiser un entier en C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
int main()
{
    int x{};
    int z = {};
    int q = 0;
    auto w = int{0};
    auto u = int(0);
    auto f = 0 + 0;
    auto e = 0;
}

Le fait que l'on puisse utiliser les parenthèses ou les accolades indifféremment dans plusieurs situations est d'une connerie sans nom ( désolé pour la vulgarité). En fonction de la méthode que vous aurez pris l'habitude d'utiliser, ça rendra très difficile de lire, naturellement et sans efforts, pour des choses très simples, le code de quelqu'un qui aura pris l'habitue d'utiliser l'autre méthode. Et c'est une source d'erreurs. Quelqu'un peut m’expliquer en quoi c'est un progrès ? Mais qu'est-ce qui est passé par la tête de ceux qui ont pondu ca ?
Stroustrup aurait du continué à être la seule personne à s’occuper de l'évolution du C++.

PS : Je comprends la colère et la frustration de Stroustrup de constater que les petits arrivistes du commité, qui s'imaginent être en train de faire l'Histoire, et qui n'ont rien compris au pourquoi du succès de ce langage, sont en train de ruiner sa création.

[bacelar]

Sources SVP

[nikau6]

Sources SVP

https://www.open-std.org/jtc1/sc22/w...19/p1962r0.pdf

Bonne lecture. Un petit apercu :

It is not just members of the community who wishes for “just two more features.” We have a committee
with 300+ members. It seems that essentially every member has a feature or two that they’d like to get
into the language, and many have several. I have not changed my opinion that adding too many features
could “sink C++.” Remember the Vasa! [Vasa]. In fact, I think that the flood of new proposals has
increased since I wrote [Vasa]. I think we are trying to do too much too fast. We can do much or do less
fast. We cannot do both and maintain quality and coherence. We have to become more restrained and
selective.

Someone might reasonably point out: “You have often expressed strong opinions and sometimes even
sounded angry when people didn’t accept your arguments or proposals.”
I should of course not show anger. Apologies. When it shows, it is typically the result of impatience after
years of work or a feeling that not everybody or every argument are held to the same standard. Also,
after years of work, it is hard to be patient with people for whom it is all new. Not only do I try not to
show anger, I try not to feel anger, but I am not a saint and I care about these issues.

Un autre papier interressant de Stroustrup. Remember the Vasa!

https://www.open-std.org/jtc1/sc22/w...18/p0977r0.pdf

Many/most people in WG21 are working independently towards non-shared goals. Individually,
many (most?) proposals make sense. Together they are insanity to the point of endangering the
future of C++.

We are on a path to disaster though enthusiasm and design-by-committee (or rather “design-by-
committees”). During the early days of WG21 the story of the Vasa was popular as warning against
overelaboration (from 1992):
Please also understand that there are dozens of reasonable
extensions and changes being proposed. If every extension that is
reasonably well-defined, clean and general, and would make life
easier for a couple of hundred or couple of thousand C++ programmers
were accepted, the language would more than double in size. We do
not think this would be an advantage to the C++ community.
We often remind ourselves of the good ship Vasa. It was to be the
pride of the Swedish navy and was built to be the biggest and most
beautiful battleship ever. Unfortunately, to accommodate enough
statues and guns it underwent major redesigns and extension during
construction. The result was that it only made it half way across
Stockholm harbor before a gust of wind blew it over and it sank
killing about 50 people. It has been raised and you can now see it
in a museum in Stockholm. It is a beauty to behold - far more
beautiful at the time than its unextended first design and far more
beautiful today than if it had suffered the usual fate of a 17th
century battle ship -- but that is no consolation to its designer,
builders, and intended users.

[mintho carmo]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
int main()
{
    int x{};
    int z = {};
    int q = 0;
    auto w = int{0};
    auto u = int(0);
    auto f = 0 + 0;
    auto e = 0;
}

Le C++ a toujours eu plusieurs syntaxes pour initialiser des variables. Il y a eu des ajouts, mais c'est comme ça depuis le début du C++. Ca vient même du C, pour dire à quel point c'est pas nouveau. Idem pour les accolades, c'est pas récent non plus, ça vient du C aussi.

Le mot clé `auto` est plus récent, mais pas le concept en soi. En C, il était possible de ne pas écrire "int" (fonctionnalité supprimée en C99). En C++, la déduction de type existait déjà avec les templates (auto est juste un template argument anonyme au final, c'est les mêmes règles de déduction).

En fonction de la méthode que vous aurez pris l'habitude d'utiliser, ça rendra très difficile de lire, naturellement et sans efforts, pour des choses très simples, le code de quelqu'un qui aura pris l'habitue d'utiliser l'autre méthode.

Bof. C'est globalement pas très dur que reconnaitre les déclarations et initialisations. Pas sur du tout que cela a un impact important sur la lecture. Et dans un projet, on va généralement se donner des guidelines et tous utiliser la même syntaxe. Ca peut être chiant d'avoir plusieurs syntaxes, mais faut pas abuser, ca rend pas la lecture "très difficile de lire".

PS : Je comprends la colère et la frustration de Stroustrup de constater que les petits arrivistes du commité, qui s'imaginent être en train de faire l'Histoire, et qui n'ont rien compris au pourquoi du succès de ce langage, sont en train de ruiner sa création.

Ne présume pas trop ce qu'il se passe dans la tête de Stroustrup. C'est plus tes propres idées dont tu parles là que les siennes. Ca fait 30 ans que c'est plus Stroustrup qui décide seul de ce qu'il y a dans le C++ et c'était un choix de sa part que ce soit comme ça. Le fait qu'il critique certains ajouts ou certaines façons de fonctionner du comité ne veut pas dire qu'il n'approuve pas les évolutions du C++. Il en a parlé dans les plenaries à plusieurs reprises à la CppCon, en particulier ce qui permet de simplifier l'écriture et la lecture du code, la sécurité, les performances, etc.

Idem pour le fonctionnement du comité, il a lui même poussé pour que le comité inclus plus de membres, d'avoir un fonctionnement plus souple pour faciliter la participation des devs pour proposer des ajouts et modifications. Et il s'est félicité de voir que c'était le cas, que le comité et la participation des devs a fortement augmenté suite à la réorganisation du comité après le C++11.

Le problème est qu'il est difficile d'avoir en même temps 2 buts : évolution et stabilité. Et Stroustrup veut bien ces 2 buts. Il a bien conscience du besoin et du bénéfice d'avoir un langage qui évolue.

Il est juste attentif au support des codes existants et à la cohérence du langage, mais cela ne veut pas dire qu'il considère que c'est son langage et que les autres membres du comité le pourrissent.

[nikau6]

Ne présume pas trop ce qu'il se passe dans la tête de Stroustrup. C'est plus tes propres idées dont tu parles là que les siennes.

Tu as bien lu les 2 articles qu'il a écrit ? Je ne présume de rien, il dit exactement ce que je prétend qu'il dit. Il peste contre l'ajout de trop nombreuses fonctionnalités, il dit que ça va trop vite, que le commité met le langage en danger, il parle de ses humeurs et de ses colères, notamment contre les nouveaux venus du comité, ces nouveaux venus l'agacent, il explique bien dans le détail plusieurs étapes qui l'ont amené à apporter certaines fonctionnalités au C++, et à quel point elles ont été réfléchi, comme pour amener les membre du comité à avoir une vision de long terme. OUI, il n'est pas content, c'est une évidence !
C'est plutôt toi qui présume.

Sinon, je sais très bien qu'il y a toujours eu plusieurs façon d'initialiser des variables. Mais cette histoire d'accolades, je persiste, c'était une très grosse connerie, et complétement inutile. Et je ne dis pas que ça rend la lecture difficile, je dis que ça la rend difficile de lire naturellement et sans efforts, lorsqu'on c'est habitué à une méthode. Ça embrouille. Et c'est pourquoi au fait ? Quelqu'un peut expliquer l’extrême nécessité qui a imposé cette règle syntaxique ? Ça devait être vachement important, mais j'ai pas compris, il faut qu'on m’explique.

Il est juste attentif au support des codes existants et à la cohérence du langage,

Et c'est justement la le problème, ce langage est en train de perdre toute cohérence, et c'est ce qu'il dénonce. Trop de propositions, il va même jusqu'à dire que les propositions des membres du comité sont incohérente et de la pure folie. Dans le deuxième article, qui est le premier que j'ai posté, il dit que depuis qu'il a écrit le premier article c'est de pire en pire, on ne l'a pas écouté. Il pense que son langage est en danger, que les décisions du comité le mette en danger, c'est écrit noir sur blanc.

PS: J'aurais mème tendance à penser que les annonces de ces grandes entreprises, qui appellent à ne plus commencer de nouveaux projets en C++, en citant pour raison la gestion non sécurisée de la mémoire, et bien je pense que ça n'est qu'un prétexte, pourquoi maintenant ? Ça n'est pas nouveau. Et quid du C ?
Alors oui il a Rust, il y a GO, mais ils sont la depuis un moment déjà.
Je pense qu'une autre des raisons qui les ont amené à ces déclarations, c'est l'hyper-complexification du langage du aux nouvelles normes.

Là j'ai présumé.

On n'en reparlera dans 10-15 ans, on verra bien ce que sera devenu ce langage. Je paris sur son déclin lié à la complexité qu'amène les trop nombreuses nouvelles normes. Les pages pour décrire ce langage ont été multiplié par combien déjà ? Et ça n'est pas fini, ça continu.
Et pourtant c'est un langage que j'aime beaucoup.

Idem pour le fonctionnement du comité, il a lui même poussé pour que le comité inclus plus de membres, d'avoir un fonctionnement plus souple pour faciliter la participation des devs pour proposer des ajouts et modifications. Et il s'est félicité de voir que c'était le cas, que le comité et la participation des devs a fortement augmenté suite à la réorganisation du comité après le C++11.

Lorsqu’il écrit ces 2 articles, on est bien après le C++11. Il semblerait qu'il ait changé d'avis entre-temps.

Le fait qu'il critique certains ajouts ou certaines façons de fonctionner du comité ne veut pas dire qu'il n'approuve pas les évolutions du C++. Il en a parlé dans les plenaries à plusieurs reprises à la CppCon, en particulier ce qui permet de simplifier l'écriture et la lecture du code, la sécurité, les performances, etc.

Bien évidement qu'il ne va pas critiquer les évolutions de son langage lors de conférences, ça serait dramatique pour la perception du langage, et très mal reçu par les autres.
Par contre dans les articles qu'il écrit, qui ont une audience beaucoup plus restreinte, il se lâche.
Dans les articles il dit bien qu'ils n'ont même pas eu le temps de consolider les nouveaux ajouts de la norme C++11, qui ont été nombreux, de son point de vue, que déjà pour la normes suivante de nouvelles fonctionnalités sont ajoutées.

[mintho carmo]

Honnêtement, je pense que tu interprètes ces articles selon ton propre point de vue, c'est pas du tout ce que je perçois de Stroustrup. Mais peu importe. Cette discussion va tourner en rond parce que c'est juste du "j'aime-j'aime pas". Ceux qui trouvent que le C++ devient trop complexe, ils sont libre de continuer a utiliser les vieilles versions du C++ ou d'utiliser un autre langage.

[Bktero]

Le fait que l'on puisse utiliser les parenthèses ou les accolades indifféremment dans plusieurs situations est d'une connerie sans nom ( désolé pour la vulgarité). En fonction de la méthode que vous aurez pris l'habitude d'utiliser, ça rendra très difficile de lire, naturellement et sans efforts, pour des choses très simples, le code de quelqu'un qui aura pris l'habitue d'utiliser l'autre méthode. Et c'est une source d'erreurs. Quelqu'un peut m’expliquer en quoi c'est un progrès ? Mais qu'est-ce qui est passé par la tête de ceux qui ont pondu ca ?

La volonté d'adresser des problèmes du langage tout en restant rétro-compatible, en grande partie.

Pour rester dans cet exemple, d’initialisation d'un entier, le langage autorise depuis toujours (certainement un comportement hérité du C) d'écrire int a = 3.14;. Pourtant, il y a bien un soucis potentiel avec cette ligne : il y a une perte d'information, car la partie décimale va être tronquée. Les compilateurs peuvent fournir des options pour alerter, mais ça ne fait pas partie du langage. Pour GCC, il faut -Wconversion, qui n'est ni dans -Wall ni dans -Wextra (et bien sûr pas dans -pedantic). L'initialisation avec accolades a été ajoutée pour éviter les conversions implicites comme celle-ci. Ainsi, int a{3.14}; et int a = {3.14}; génèrent une erreur : error: narrowing conversion of ‘3.1400000000000001e+0’ from ‘double’ to ‘int’ [-Wnarrowing].

On parle souvent de Rust comme étant le concurrent de C++. Rust n'autorise pas une telle conversion. Ainsi, let a: i32 = 3.14; génère une erreur, il faut faire un cast pour que le compilateur accepte la déclaration : let a: i32 = 3.14 as i32;. C'est par défaut dans le langage, ce n'est pas une option de compilateur. D'ailleurs, on ne peut pas dire :

A régler avec des options de compilation.

A ma connaissance, la norme C++ n'utilise pas la notion d'options de compilation. Il y a le langage et c'est tout.

Fallait-il adresser ce "défaut" du C++ via le langage lui-même ? Peut-être, peut-être pas. Mais si on souhaite l'adresser, on ne peut pas juste dire "à partir de C++2X, int a = 3.14; est invalide et ne compile plus". On est obligé de trouver une astuce. Cette astuce, c'est l'ajout d'une nouvelle syntaxe. Il n'y a pas de réelle autre alternative.

Cette volonté de rétro-compatibilité est à la fois la force et la faiblesse de C++. La force, c'est que tu peux faire du compiler du vieux code contre des normes modernes facilement. J'ai récemment fait l'exercice de passer une grosse base de code de C++14 à C++20, et c'était assez facile. Une grosse partie du taff a été de me débarrasser des std::experimental qui n'étaient plus expérimentaux justement, comme std::optional. La faiblesse, ce sont des tonnes de syntaxes, de fonctions. Des trucs restent dans le langage (ou en tout cas mettent des plombes à être deprecated ou removed, et il s'agit surtout de fonctionnalités de la bibliothèque) au lieu d'être remplacés purement et simplement.

Avis personnel : mais quel enfer l'initialisation en C++ !

[Axel Mattauch]

La volonté d'adresser des problèmes du langage tout en restant rétro-compatible, en grande partie.

[...]

A ma connaissance, la norme C++ n'utilise pas la notion d'options de compilation. Il y a le langage et c'est tout.

Fallait-il adresser ce "défaut" du C++ via le langage lui-même ? Peut-être, peut-être pas. Mais si on souhaite l'adresser, on ne peut pas juste dire "à partir de C++2X, int a = 3.14; est invalide et ne compile plus". On est obligé de trouver une astuce. Cette astuce, c'est l'ajout d'une nouvelle syntaxe. Il n'y a pas de réelle autre alternative.

Cette volonté de rétro-compatibilité est à la fois la force et la faiblesse de C++. La force, c'est que tu peux faire du compiler du vieux code contre des normes modernes facilement. J'ai récemment fait l'exercice de passer une grosse base de code de C++14 à C++20, et c'était assez facile. Une grosse partie du taff a été de me débarrasser des std::experimental qui n'étaient plus expérimentaux justement, comme std::optional. La faiblesse, ce sont des tonnes de syntaxes, de fonctions. Des trucs restent dans le langage (ou en tout cas mettent des plombes à être deprecated ou removed, et il s'agit surtout de fonctionnalités de la bibliothèque) au lieu d'être remplacés purement et simplement.

Tout a fait d'accord sur tous les points: le sujet porte bien sur la notion de compromis (ou d'optimum).
Comme le signale avec pertinence Bjarne Stroustrup ( voir documents suggérés par nikau6)

It is easier to point to problems than to suggest remedies.

Je me suis peut-être mal exprimé en parlant d'option de compilation: Mais compiler soit en C++20 soit en C++14 n'est-ce pas un paramétrage du compilateur? Quid des variantes ISO?

Pour reprendre l'exemple int a = 3.14; // valeur affectée= 3 je considère qu'il aurait été plus sain de pouvoir choisir dans le compilateur que cette tolérance était deprecated à partir d'une certaine génération de la syntaxe C++.
Parce que: non, la compatibilité ascendante n'est pas assurée, mais (et je loue bien cette caractéristique du C++) hautement favorisée.

Et cet exemple est justement ce que je reproche: créer une nouvelle syntaxe plutôt que supprimer une tolérance pour une syntaxe trop permissive.
Mais je ne prétends pas avoir l'expérience ni le recul pour juger de ces choix, je laisse ce soin aux experts:

We are defining a language for decades of use. A bit of humility is necessary

Les évolutions sont faites d'extensions et de suppressions. A défaut de suppressions dans la syntaxe du langage même (voir par exemple les syntaxes d'initialisation signalées par nikau6), un guide qui indiquerait "depuis C++N, pour faire une initialisation privilégie la syntaxe sn" serait déjà pas mal. Et tant qu'à faire: oublions les syntaxes S0, S1...

[Pyramidev]

Fallait-il adresser ce "défaut" du C++ via le langage lui-même ? Peut-être, peut-être pas. Mais si on souhaite l'adresser, on ne peut pas juste dire "à partir de C++2X, int a = 3.14; est invalide et ne compile plus". On est obligé de trouver une astuce. Cette astuce, c'est l'ajout d'une nouvelle syntaxe. Il n'y a pas de réelle autre alternative.

Depuis que le C++ a enfin des modules, une solution intéressante serait d'avoir un mécanisme d'époques.
Rust a d'ailleurs déjà ce mécanisme (les époques y sont appelées des éditions).
Dans l'exemple présent, on pourrait alors dire que, à partir d'une certaine époque, les conversions implicites sont plus restreintes. Le code historique pourrait rester dans une époque plus ancienne.

[Bousk]

Il existe 7 façons d'initialiser un entier en C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
int main()
{
    int x{};
    int z = {};
    int q = 0;
    auto w = int{0};
    auto u = int(0);
    auto f = 0 + 0;
    auto e = 0;
}

Que 7 ? Tu en oublies une infinité voyons.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
int g = 1;
int h = 2;
auto hh = 2;
...
int i = 0 + 0;
auto j = 0 * 0;
auto k = 0 / 2;
...
auto l = someMethod();
auto m = something() + 0;
...

[mintho carmo]

Tout a fait d'accord sur tous les points: le sujet porte bien sur la notion de compromis (ou d'optimum).
Comme le signale avec pertinence Bjarne Stroustrup ( voir documents suggérés par nikau6)

Je me suis peut-être mal exprimé en parlant d'option de compilation: Mais compiler soit en C++20 soit en C++14 n'est-ce pas un paramétrage du compilateur? Quid des variantes ISO?

Pour reprendre l'exemple int a = 3.14; // valeur affectée= 3 je considère qu'il aurait été plus sain de pouvoir choisir dans le compilateur que cette tolérance était deprecated à partir d'une certaine génération de la syntaxe C++.

En pratique, c'est le cas. Comme a dit Bktero, tu peux activer des options de compilation qui vont faire des vérifications plus strictes et signaler certaines syntaxes qui sont syntaxiquement valides mais posent problèmes. Et on peut ajouter en plus les outils d'analyse statiques.

Mais comme a dit Bktero, le problème est que dans Rust, la philosophie est d'interdire par défaut et autorisé si explicite, alors qu'en C++, c'est l'inverse. Certains considèrent alors que le C++ n'est pas safe parce que les contraintes sont pas dans le langage mais dans les outils et l'écosystème. (Mon point de vue, c'est que cela n'a pas de sens de regarder que le langage et pas l'ensemble de l'écosystème).

créer une nouvelle syntaxe plutôt que supprimer une tolérance pour une syntaxe trop permissive.

Le problème, c'est que ce n'est pas si simple à gérer. Cela impose que toutes les libs qui sont include respectent aussi les contraintes sur les syntaxes. Ce qui n'est pas du tout simple et imposerait en pratique aux devs des libs de gérer plusieurs versions.

C'est pour cela que Epoch n'avance pas beaucoup. Il faut espérer que maintenant qu'il y a les modules, cela va rendre possible d'ajouter les Epochs.

un guide qui indiquerait "depuis C++N, pour faire une initialisation privilégie la syntaxe sn" serait déjà pas mal. Et tant qu'à faire: oublions les syntaxes S0, S1...

De tels guide existent. Par exemple les C++ Core Guidelines https://isocpp.github.io/CppCoreGuid...CoreGuidelines. Mais les problèmes restent les mêmes :

- c'est optionnel, donc les devs sont libres de ne pas les suivre
- tout le monde ne connait pas ces guidelines
- tout le monde n'est pas d'accord sur ces guidelines

Pour cela que je ne partage pas forcément toutes les critiques sur le C++. Parce que pour moi :

- pour l'apprentissage, il faut accepter de ne pas vouloir apprendre toutes les syntaxes. C'est complètement idiot, si on fait un cours de C++, de dire "on va voir les 57 syntaxe différentes pour initialiser une variable" alors qu'on va en utiliser 1 ou 2 en pratique et qu'on oubliera les autres.
- il faut utiliser l'ensemble des outils de prod de logiciel, pas juste un compilateur sans aucun warning activé. En particulier les outils d'analyse statique.

Cela ne veut pas dire que Rust n'a pas de vrais avantages par rapport au C++. Mais il a aussi un écosystème moins mature que le C++. La question est donc de savoir si on fait le pari de rester en C++ et profiter des évolutions qu'il va bénéficier, ou de passer sur Rust et parier sur les évolutions de son écosystème. (j'ai fait le premier pari)