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)