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

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

[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++ !

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