Le C++ est vraiment amusant

 (learncodethehardway.com)
1 points par GN⁺ 2024-12-25 | 1 commentaires | Partager sur WhatsApp
  • Depuis C++11, le langage et son écosystème ont profondément changé, et le processus de construction et d’expérimentation en a fait un langage qui redonne le plaisir de programmer
  • À une époque, beaucoup de développeurs gardaient du C++ le souvenir d’un langage fatigant, à cause de l’excès de métaprogrammation par templates et d’une culture centrée sur les standards et les patterns
  • Des évolutions comme auto, nullptr, range-for, les lambdas, <chrono>, les smart pointers et <thread> ont profondément transformé le style de code en C++
  • Le C++ moderne offre aujourd’hui un large éventail d’options, du système de fichiers à la gestion de paquets, en passant par les GUI/TUI, les graphismes, les mathématiques, l’IA et l’accès aux API système, ce qui facilite la création directe de ce qu’on veut
  • Les défauts subsistent — erreurs de compilation, outils de build, conformité aux standards, complexité historique, RAII — mais la capacité de création l’emporte sur ces désagréments

Pourquoi le C++ est redevenu amusant

  • En créant un petit jeu roguelike, l’auteur a utilisé l’algorithme de Dijkstra pour générer des tunnels reliant des salles sur la carte, et dans ce processus le C++ n’a pas fortement freiné l’expérimentation
  • Il a aussi été possible d’expérimenter en dessinant directement l’interface utilisateur de FTXUI dans une fenêtre de rendu SFML, ce qui a aussi permis d’apprendre le traitement Unicode en C++
  • Ce n’était pas facile, mais c’était réellement faisable, et ce sentiment de « cette idée a vraiment fonctionné » est au cœur du plaisir du C++
  • La raison de départ pour programmer n’était pas de faire gagner encore plus d’argent à des milliardaires, de se battre avec un moteur de rendu ou de satisfaire la hiérarchie d’un projet open source, mais bien le plaisir de concrétiser des idées

La fatigue de l’époque de la métaprogrammation par templates

  • De la fin des années 1990 au début des années 2000, le C++ a connu une période où l’on voulait appliquer la métaprogrammation par templates à tout, et cette époque est présentée comme un tournant qui a rendu le C++ moins amusant
  • On voyait par exemple des discussions affirmant qu’additionner deux nombres via des templates était plus rapide que de les additionner directement, alors que le code assembleur produit était en réalité identique
  • L’idée que le comité de standardisation du C++ se souciait peu d’offrir une bonne ergonomie aux programmeurs a aussi nourri cette expérience négative
  • Le C++ de l’époque est resté dans les mémoires comme un langage plein de chevrons <> et de syntaxe complexe, pour peu de bénéfices en retour
  • Java semblait lui aussi séduisant au départ grâce au garbage collector et à son approche conviviale pour les développeurs, avant de produire une fatigue comparable avec l’excès de boilerplate et de design patterns

Ce que C++11 a changé dans la sensation du langage

  • Les fonctionnalités ajoutées dans C++11 sont considérées comme un tournant majeur dans la perception du C++
  • Parmi les principales évolutions :
    • auto : mot-clé d’inférence automatique de type qui évite de répéter sans cesse le même nom de type
    • nullptr : représentation du pointeur nul qui corrige les problèmes de NULL en C
    • range-for : boucle qui, avec auto, simplifie l’itération sur les conteneurs
    • lambda expressions : les lambdas, capables de transformer profondément la conception et l’ergonomie des API
    • <chrono> : bibliothèque de temps sûre du point de vue des types, avec des expressions comme 100ms
    • <regex> : support des expressions régulières dans la bibliothèque standard
    • unique_ptr, shared_ptr : smart pointers pour gérer propriété et comptage de références
    • <thread> : prise en charge du multithreading dans l’écosystème de base du langage
  • C++11 n’a pas supprimé les anciennes manières de faire, mais il a changé la philosophie et le style du langage, un peu comme ES6 pour JavaScript

Les options de l’écosystème C++ moderne

  • Le C++ moderne dispose aujourd’hui de nombreuses fonctionnalités qu’on attendrait d’autres langages
  • Exemples d’outils et de bibliothèques cités :
  • La qualité de l’écosystème varie selon les domaines, mais elle est globalement jugée supérieure à ce que l’auteur a connu en JavaScript et Python
  • FTXUI et la STL sont notamment cités comme de bons exemples de conception et d’ergonomie

Une large capacité d’implémentation qui crée le « plaisir »

  • Si le C++ est amusant, ce n’est pas seulement parce qu’il a gagné des fonctionnalités modernes, mais parce qu’il permet de réaliser presque tout ce qu’on veut
  • On peut créer des applications desktop avec fenster, SFML, Qt, ou en manipulant directement les API du système d’exploitation
  • Pour l’audio, le choix va de solutions rapides comme SFML à des outils commerciaux comme Wwise
  • Pour la 3D, il existe diverses options comme OpenGL, Vulkan, Direct3D ou Ogre3D
  • Côté mathématiques, on trouve des bibliothèques comme BLAS, Eigen, GMTL
  • Et même si la bibliothèque nécessaire n’existe pas, il est possible de la construire soi-même via l’ABI C ou C++ et les API du système d’exploitation, ce processus direct de fabrication faisant lui aussi partie du plaisir

La liberté créative d’un langage hors des modes

  • Le C++ est jugé de grande qualité, tant comme langage que comme écosystème, mais ce n’est pas le langage à la mode du moment, ce qui lui vaut selon l’auteur d’être moins exposé à certains types d’attention qui finissent par abîmer un langage
  • La communauté C++ est décrite comme un milieu qui intervient peu sur ce qu’on choisit de construire
    • On peut librement tenter des projets comme une bibliothèque de matrices, une bibliothèque GUI, un moteur de jeu ou un jeu étrange
  • Le travail créatif a besoin à la fois d’une phase où l’on fait sortir les idées et d’une phase ultérieure où l’on les critique froidement pour en améliorer la qualité
  • Dans d’autres langages, l’organisation, le leadership ou la pression communautaire sont présentés comme des freins aux expérimentations de milieu de parcours
  • L’ampleur des possibilités en C++ et sa culture relativement moins portée sur la culpabilisation peuvent ainsi produire une expérience créative

Les points forts de cppreference.com

  • cppreference.com est considéré comme l’une des meilleures documentations de langage de programmation que l’auteur ait utilisées
  • Ses atouts :
    • tous les mots-clés et toutes les bibliothèques y sont organisés en documentation de référence
    • la plupart des entrées proposent des exemples réellement fonctionnels
    • la version du standard C++ ayant introduit chaque fonctionnalité est indiquée
    • des liens vers les documents de standardisation et d’autres références pertinentes sont fournis
    • une barre de recherche basée sur DuckDuckGo facilite la recherche, même en cas de faute de frappe ou si l’on ne connaît pas le terme exact
    • des concepts importants comme Copy elision sont expliqués avec des exemples
  • Son principal manque est l’absence d’explications sur l’installation des compilateurs selon les différentes plateformes
  • Comme il n’existe pas tant de compilateurs C++ ni tant de plateformes que cela, il y aurait de la place pour un guide de démarrage

Les problèmes du C++ qui restent

  • Cela ne veut pas dire que le C++ est un langage parfait ; comme les autres, il comporte beaucoup d’inconvénients
  • Sous Windows, configurer un compilateur et des outils de développement en dehors du chemin d’installation Microsoft est difficile, et l’auteur a donc créé lui-même un script d’installation PowerShell
  • Parmi les principaux problèmes ressentis aujourd’hui :
    • plus de 95 % des messages d’erreur du compilateur sont jugés parmi les pires du secteur
    • les outils de build sont difficiles à utiliser, et Meson a lui-même posé problème en ignorant les paquets installés pour utiliser à la place des bibliothèques système cassées
    • les éditeurs de compilateurs ont peu d’incitations à respecter strictement le standard
    • le C++ est extrêmement complexe à cause de son histoire, avec coexistence d’un ancien style basé sur l’allocation sur le heap et les raw pointers, d’un style centré sur la métaprogrammation par templates, d’un style plus orienté pile apparu après C++11, et d’un style encore plus récent centré sur struct
    • le RAII gêne souvent dans des situations de configuration réelles, et l’auteur estime qu’il manque un juste milieu entre des constructeurs d’initialisation inspirés d’autres langages et le RAII actuel
  • Malgré ces défauts, les désagréments du C++ ne suffisent pas à gâcher le plaisir, et le langage ne correspond plus à l’image ancienne d’un monde de chevrons et de pointeurs
  • Le code de layout GUI de FTXUI montre même une syntaxe si moderne qu’on ne le prendrait pas forcément pour du C++ si on ne le savait pas

À lire aussi

1 commentaires

 
GN⁺ 2024-12-25
Avis sur Hacker News

  • Je suis plutôt proche d’un détracteur de C++, mais c’est parce que je déteste devoir travailler avec C++ sur du code métier qui exige de la fiabilité, avec des collègues en qui il est difficile d’avoir pleinement confiance.
    Pour des projets personnels, ça reste l’un des environnements de programmation les plus satisfaisants que j’aie connus, et le fait de pouvoir contrôler l’exécution avec une très grande finesse est vraiment grisant.
    J’ai quitté C++ il y a environ 10 ans et je n’ai pas l’intention d’y revenir, mais pour mes projets actuels, la fiabilité à long terme est primordiale, donc Rust + CI/CD me convient parfaitement.
    Cela dit, le frisson de concevoir et d’implémenter un programme pour qu’il s’exécute exactement comme je l’ai prévu, et de savoir que c’est grâce à mon expertise et à mon intuition, me manque.
    Est-ce que je voudrais que les gens avec qui je travaille soient animés par ce genre de motivation ? Absolument pas. Mais à titre personnel, c’est un plaisir inoubliable.
    Les systèmes de build et la gestion des paquets sont un cauchemar, le préprocesseur ressemble à une blague sadique, la syntaxe est affreuse, et au runtime il reste trop de scories qui exigent des années d’expérience pour éviter de se tirer une rafale de mitraillette dans le pied.
    Mais, d’une certaine manière, ces souffrances rendent encore plus grande la joie de finalement produire un exécutable enveloppé d’intelligence et de larmes de sang.

    • C’est l’une des descriptions de C++ dans lesquelles je me reconnais le plus.
      J’ai utilisé C/C++ pendant plusieurs années au travail et je n’ai aucune envie d’y revenir.
      J’ai passé beaucoup trop de temps à déboguer le code des autres, à subir des problèmes d’intégration ambigus et à faire tourner des spaghettis de systèmes de build.
    • Le travail devrait être aussi amusant que les projets personnels.
      J’ai l’impression que l’industrie tech a perdu cette idée au cours des dix dernières années, et j’en tiens pour responsables les grandes entreprises tech qui enferment les meilleurs profils dans des prisons pour adultes avec de la bonne nourriture et des fauteuils moelleux.
      Les startups aussi sont devenues moins fun, et le monde du VC encourage une fenêtre de pensée étroite, avec trop de startups clones qui fabriquent la même chose et trop d’effets de mode.
      Si j’utilise C++ pour chaque nouveau projet, c’est parce que j’ai la certitude de pouvoir construire moi-même ce dont j’ai besoin.
      Les frameworks, surtout lorsqu’ils touchent au cœur du projet, ne se comportent souvent pas comme je le souhaite, et je finis par ne plus vouloir les utiliser.
      Si tu peux le construire toi-même, fais-le ; sinon, utilise un framework.
      Si tu sais le construire toi-même, C++ est un excellent outil capable de tout faire et qui, sur les aspects importants, ne te gêne pas.
      Un langage comme Rust peut se plaindre que je fais quelque chose de dangereux, mais en C++, je peux exprimer directement le modèle que j’ai en tête.
      Parfois, je pense en pointeurs, et les pointeurs sont vraiment de très bons outils.
      Retrouvons le plaisir, pas seulement dans la vie personnelle, mais aussi au travail.

  • Cet article me paraît assez confus.
    Il aborde beaucoup de points, mais il est difficile d’en tirer pourquoi cela mènerait à la conclusion que C++ est plus amusant, ou moins amusant.
    C’est aussi déroutant de qualifier le C++ moderne de qualité extrêmement élevée tout en parlant de vastes problèmes hérités du passé et d’outils horribles.
    Dire que unique_ptr est excellent tout en affirmant détester vraiment RAII, ou prétendre que la métaprogrammation était omniprésente autrefois mais ne l’est plus maintenant, est également étrange.
    Il suffit de regarder concepts pour voir que ce n’est pas le cas ; et les affirmations selon lesquelles C++ aurait les meilleures bibliothèques graphiques, ou que l’installation de Python serait plus difficile que celle de C++, ressemblent davantage à des obsessions de l’auteur sans grand rapport avec le propos.
    Au final, l’auteur semble trouver C++ amusant pour une combinaison complexe de raisons personnelles, et c’est très bien comme ça.
    J’ai moi aussi connu mes moments de programmation les plus amusants en C++, grâce à ses performances et à son caractère technique, mais dans le développement logiciel réel, C++ est médiocre pour les innombrables raisons que l’on connaît.
    C++ est un langage profondément contradictoire, marqué par des décennies de legacy et de politique, et ignorer la réalité de C++ est la plus grosse erreur dans les discussions à son sujet.
    Aujourd’hui, mon attitude envers C++ relève plutôt de la lassitude, et je n’ai plus envie de franchir les obstacles que C++ a dressés pendant toutes ces années.
    Inutile de continuer à battre un cheval mort depuis trop longtemps ; on peut simplement laisser C++ être C++.

    • Je trouve que cette phrase résume bien l’idée de l’article.
      À mes yeux, l’article est moins confus qu’enthousiaste : l’auteur prend du plaisir et essaie de le partager autant que possible.
      Ce n’est pas vraiment une tribune structurée ni un texte qui cherche activement à convaincre ; c’est plutôt du genre « si tu n’as pas besoin d’être convaincu et que ça te parle, alors ça pourrait aussi t’amuser ».
      Je comprends tout à fait que, si l’on est fatigué après s’être heurté à la réalité du travail commercial, cela puisse sembler absurde.
      Moi aussi, en ce moment, je prends énormément de plaisir, justement avec JavaScript, et si j’écrivais un article similaire, il serait probablement tout aussi mal reçu par quelqu’un épuisé par dix ans de JavaScript commercial.
      Cela dit, je suis content que l’auteur s’amuse et qu’il ait choisi de partager ce plaisir.

  • J’ai passé 3 jours à lier statiquement une dépendance tierce dans un projet C++ pour qu’elle fonctionne sous Linux/Windows/macOS.
    Ce paquet n’était ni dans conan ni dans vcpkg ; il n’y avait qu’un dépôt GitHub avec une combinaison bizarre de Makefile/cmake.
    Je suis loin d’être expert en cmake/cpp, mais dans la plupart des langages modernes, ce genre de chose ne pose pas de problème avec pip install, cargo add, npm install, go get, etc.
    Même si l’on lit de bout en bout un livre sur les détails de la sémantique de C++, travailler sur un vrai projet reste douloureux.

    • Les dépendances JavaScript et les chaînes d’outils de build sont aussi obscures que les Makefile les plus sales.
      C’est étonnant d’en être arrivé à quelque chose comme des autotools version JavaScript.
    • Je suis curieux de savoir ce qui a été difficile exactement.
      Construire statiquement le code de quelqu’un d’autre, ou le modifier pour qu’il se compile sur d’autres plateformes, peut parfois être délicat, mais l’édition de liens elle-même se résume généralement à indiquer le répertoire d’includes, le chemin des bibliothèques et les bibliothèques à utiliser.
    • Vu autrement, si tu voulais utiliser cette dépendance tierce depuis un autre langage « moderne », qu’est-ce qui serait vraiment mieux ?
      Si personne n’a fait le packaging vcpkg/conan, il y a de fortes chances qu’elle ne soit pas non plus dans pip/cargo/npm.
      Si c’était difficile en C++, cela pourrait être encore bien plus difficile dans un autre langage.
      Cela dit, cela montre aussi qu’une partie de l’histoire de C++, en particulier la question du build, est dans un très mauvais état.
      Dès que c’est disponible dans vcpkg, la difficulté d’installation devient exactement comparable à celle des autres écosystèmes.

  • Je travaille périodiquement en C++ plutôt qu’en C, et c’est toujours le même schéma
    Je découvre une nouvelle technique C++, j’écris du code en me disant que ça va améliorer les choses, je me prends des erreurs du compilateur, puis je passe le reste de la journée à comprendre pourquoi je ne peux pas faire ce que je veux
    Je suis généralement bloqué à C++14, et certains problèmes ont été corrigés dans les versions ultérieures, mais quand même
    J’aimerais vraiment aimer le C++ : en théorie, il offre un C plus puissant qui devrait augmenter la productivité, mais au final la charge cognitive est telle que je finis en général par écrire du « C avec des classes » et passer à autre chose

    • Il y a un moment où apprendre devient amusant, et l’auteur du billet semble encore s’y trouver
      En 2003, j’ai beaucoup utilisé le C++ temps réel et je l’ai détesté, mais l’an dernier j’ai écrit la majeure partie de mon code en C++ et j’ai enfin fini par l’apprécier
      Les lambdas et auto ont été le tournant qui m’a permis de ne plus détester le C++
      J’ai aussi utilisé un peu les templates, mais surtout pour éviter d’avoir des tas de branches pour chaque variante d’une même fonction
      Grâce aux lambdas, je peux écrire du code comme les profs de la famille Lisp, dans l’esprit de SICP, me l’avaient appris au départ
      Avec unique_ptr, les allocations ne me déplaisaient pas non plus
    • J’ai vu beaucoup de mauvais code écrit par des gens qui venaient tout juste d’apprendre une fonctionnalité et voulaient absolument l’utiliser
      Il ne faut pas faire ça : il faut d’abord réfléchir à la manière dont le code sera utilisé, puis employer une fonctionnalité si elle résout le problème
      C’est problème → solution, pas l’inverse
      Par exemple, les templates C++ sont généralement horribles, mais le duck typing à la compilation ou l’ajout automatique de padding basé sur sizeof() peuvent parfois être très utiles
    • Mon expérience du C++ a été exactement celle-là
      Au départ, j’étais programmeur C# et j’apprenais le C à cause d’un projet embarqué, et le déroulé était identique
      Le C++ a beaucoup de fonctionnalités élégantes qui paraissent puissantes si elles correspondent exactement à l’application
      Mais chaque fois que j’essayais une nouvelle fonctionnalité, ce que je voulais faire était toujours un cas limite qui ne fonctionnait pas dans cette situation, et après des heures ou des jours d’essais j’abandonnais pour l’écrire simplement en C
    • Le C++, comme la plupart des technologies, fonctionne mieux si l’on fait l’effort de l’apprendre correctement
      Bien sûr, il existe des langages comme Python ou Ruby qui échappent un peu à cette tendance
    • ChatGPT ou Copilot aident beaucoup sur ce genre de choses
      En général, je copie le texte de l’erreur et je leur demande de le déchiffrer

  • Le C++ est vraiment amusant, et je pense que les griefs des gens dépendent énormément du contexte
    Beaucoup de développeurs C++ détestent le langage, mais cette haine est parfois mal orientée
    En réalité, ils travaillent souvent sur des produits legacy écrits par des gens qui ne maîtrisaient pas très bien le logiciel
    J’ai vécu quelque chose de similaire avec Rust : on m’a affecté à un projet Rust existant dans mon entreprise, et la vieille base de code contenait beaucoup de conventions contradictoires
    Il y avait des types de gestion d’erreurs qui se composaient mal, de mauvaises abstractions de classes, des blocs unsafe inutiles, etc., et c’était le projet le plus pénible que j’aie jamais fait
    Il est facile d’accuser Rust, mais en réalité c’était simplement du mauvais développement logiciel
    Le C++ a bien des défauts, mais une grande partie de la douleur que les gens ressentent vient du fait qu’ils travaillent sur du mauvais code qui serait catastrophique dans n’importe quel langage

    • Dans presque tous les autres langages que C, écrire v[x]=y n’invite pas une corruption mémoire arbitraire à chaque fois
      Avec std::optional en C++, appeler *v quand v est vide entraîne un comportement indéfini
      Le but d’un optional est de contenir une valeur qui peut être absente ; j’ai du mal à comprendre pourquoi l’opération la plus courante sur un optional vide devrait produire un comportement indéfini
      Pour avoir beaucoup utilisé le C++, le problème est que tous les programmeurs du projet doivent être parfaits à 100 %, 100 % du temps
      On peut lancer des vérificateurs mémoire et le mode debug de la STL, mais si on ne les exécute pas aussi en release, il faut espérer que la suite de tests couvre toutes les bizarreries qu’un utilisateur stupide ou malveillant pourrait déclencher
      À une époque où le logiciel est devenu aussi important et où Rust semble approcher les performances du C++, je me demande s’il vaut encore la peine d’utiliser un langage dont beaucoup de fonctionnalités de base sont très difficiles à employer en toute sécurité
      Et la situation empire même : appeler un std::function vide lançait un assert, mais le nouveau std::copyable_function en fait un comportement indéfini
    • J’ai du mal à être d’accord avec ça
      Le système de types est agaçant, sans pour autant offrir une vraie sécurité mémoire
      Le most vexing parse est vraiment vexant, et les bizarreries héritées du C, comme la dégradation des pointeurs, sont toujours là
      Par-dessus, on ajoute de nouvelles solutions comme std::array, sans pouvoir supprimer les anciennes
      Le fait de continuer à dépendre du préprocesseur pour imiter un vrai système d’import de modules est aussi un problème, et cela entraîne des contournements comme l’organisation du code des classes ou l’idiome pimpl
      Fondamentalement, les défauts sont trop grands et trop nombreux pour que j’arrive encore à y trouver de la beauté
    • C’est vrai, mais plus un langage est complexe, plus il est facile de produire un bazar incompréhensible
      À l’inverse, un projet dans un langage blub simple se déchiffre généralement assez facilement, quel que soit l’état de la base de code
    • Même s’il date, le C++ FQA reste assez drôle et mérite le détour : https://yosefk.com/c++fqa/

  • Tant mieux si quelqu’un trouve du plaisir avec C++, mais personnellement, après l’avoir subi pendant plus de 20 ans, je pense qu’il est temps d’en finir avec C++
    C’est juste le bazar
    Si j’ai vraiment besoin d’un contrôle bas niveau, je préfère utiliser C malgré ses défauts ; sinon Rust, Python, etc. me rendent bien plus heureux

    • D’accord
      Cela dit, C++ va rester
      Il y a trop de code écrit dans ce langage, c’est clairement une compétence utile à acquérir, et il existe aussi des postes très bien payés
      Pour moi, le langage se met trop en travers du chemin et me paraît excessivement complexe
      Je connais le discours selon lequel le « C++ moderne » est excellent, qu’il n’est pas nécessaire d’apprendre les anciennes versions, et que chaque nouvelle version le rend plus simple
      Le problème, c’est que les bases de code sur lesquelles on finit réellement par travailler ne sont pas du C++ moderne
      Elles utilisent toutes les fonctionnalités sorties jusqu’ici, elles sont difficiles et pleines de pièges
      Quelqu’un qui a fait du C++ pendant des années uniquement sur ses propres projets peut développer une certaine expertise et devenir immunisé à cette complexité, mais ce n’est vraiment pas un bon langage
    • L’une des choses qui ont rendu C++ plus supportable avec le temps, c’est qu’il est devenu assez facile de remplacer naturellement la plupart des éléments par des implémentations qui se comportent comme on l’entend et dont le comportement est suffisamment défini
      Par exemple en remplaçant les types de données de base, la bibliothèque standard, etc.
      Surtout depuis C++20, les bases de remplacement semblent assez natives et expressives
      Beaucoup de nouveaux projets C++ que je vois suivent fortement cette direction
      Le fait de pouvoir créer facilement un langage spécifique au domaine, de niveau système, pour une application est l’un des points forts de C++
    • Dans un projet dérivé d’Ultima que je faisais en C++/SDL2, je n’utilisais que quelques fonctionnalités de C++
      Malheureusement, je ne l’ai pas terminé, mais je me souviens surtout des classes, de std::function, std::unordered_map, std::string et std::unique_ptr
      J’ai du mal à imaginer lire le code de quelqu’un d’autre s’il n’est pas dans un style similaire
      Comme je n’utilise pas professionnellement de grands programmes, le plus difficile a été de dépasser les patterns de programmation comme le pattern Visitor
      J’aurais aimé que C++ s’arrête à C++11
      Le comité semble maintenant vouloir tout mettre dans le langage, et C++ ressemble à un langage gigantesque qui prend en charge tous les styles de programmation de niche
    • C++ est un bazar complet
      Mais c’est un bazar amusant, et j’aime écrire en C++
      Parfois, c’est important
      Ma relation avec Rust est bien plus froide
      Je respecte Rust, je l’utilise quand je pense que c’est le bon choix, surtout dans des contextes où il est difficile de défendre l’usage de C++, comme au travail, et je pense que ce que fait Rust est important
      Mais même après avoir mené pas mal de projets Rust jusqu’ici, je trouve son utilisation ennuyeuse
      Sur des aspects essentiels, il est meilleur, mais au moins pour moi, il est moins agréable
    • Rust n’est-il pas aussi un langage qui cherche à offrir le même contrôle et le même bas niveau que C ?
      Si l’on lève le verrou de unsafe, on peut convertir explicitement des entiers en pointeurs et, par exemple, contrôler du matériel avec des entrées/sorties en mémoire mappée, non ?

  • Cet article est une longue tirade au périmètre large, et le seul mot « C++ » peut suffire à déclencher les gens, ce qui fait que beaucoup d’éléments peuvent être ignorés
    Ça m’arrive aussi
    Pour les griefs, il faut passer directement à la section « It's Not All Puppies and Butterflies »
    L’auteur a été très impressionné par C++11, et après avoir délibérément ignoré C++ pendant près de 20 ans, j’ai ressenti à peu près la même chose
    J’apprécie qu’il présente des packages et des bibliothèques avec lesquels jouer, mais intégrer une autre bibliothèque à mes projets reste souvent pénible
    Les en-têtes en fichier unique me viennent à l’esprit
    FTXUI est intéressant
    Et vraiment, cppreference.com est excellent
    La documentation Python est plutôt bonne aussi, mais je n’ai jamais vu de documentation aussi bonne que cppreference.com

    • cppreference.com est, comme son nom l’indique, une excellente documentation de référence
      La documentation Python est dispersée à plusieurs endroits, incomplète à divers égards, et manque aussi d’un style éditorial cohérent
      Mais selon le framework Diataxis, elle couvre plutôt bien plusieurs types de documentation, pas seulement la référence
      Les personnes qui l’écrivent prennent explicitement ce framework en compte pour chercher des pistes d’amélioration
      Cela reste toutefois un travail open source fondé sur le bénévolat, qui avance à peu près comme le développement de code
    • Après avoir appris C++ au lycée et à l’université, je suis rapidement passé à Python/JavaScript au travail, et cet article m’a permis de combler beaucoup de lacunes sur C++
      Depuis un moment, j’avais envie de me rapprocher « du système », et apprendre Rust en parallèle n’a pas été facile non plus
      En lisant cet article, j’ai retrouvé l’espoir que réapprendre C++ pourrait rendre cela possible
      Bonjour CMake… non, peut-être devrais-je dire Meson

  • Je suis d’accord pour dire que C++ est excellent si une équipe talentueuse sait bien utiliser le C++ moderne et démarre un nouveau projet
    C’est un langage agréable et puissant, performant et, même s’il est complexe, le débogage et l’optimisation y sont relativement intuitifs
    J’ai eu l’occasion de travailler sur une base de code d’environ 5 ans, écrite selon les standards postérieurs à C++11, et c’était très agréable pour plusieurs des raisons évoquées dans l’article
    En revanche, avec une vieille base de code ayant évolué pendant 20 à 30 ans, ou une base de code qui n’a pas été maintenue par des personnes compétentes, l’expérience serait tout autre

    • J’ai commencé ma vie de développeur avec PHP, en apprenant sur le tas en créant des thèmes WordPress sur mesure avec des plugins pour des types de données spécifiques
      À 21 ans, mon entreprise m’a proposé de payer mes études, je suis donc retourné suivre un cursus d’ingénierie informatique, que j’ai ensuite changé pour l’informatique
      Le premier jour du cours « introduction à la programmation », dès que j’ai touché à C++, je suis tombé amoureux
      Par rapport à PHP 7 que j’utilisais à l’époque, le système de types, le débogage et l’écosystème étaient excellents
      Avec l’accord de mon manager, j’ai créé des API en C++ pour certaines applications intranet existantes, que PHP appelait via des WebSockets, ce qui m’a permis de tirer parti du système de types et des performances
      Ces systèmes sont encore utilisés tous les jours dans toute l’entreprise, et la maintenance n’a pas posé de problème
      Et ce, même s’ils tournent dans un environnement assez particulier appelé IBM Pase for i
      Aujourd’hui, après avoir utilisé Rust et Axum, je préférerais largement l’écosystème Rust pour créer ce genre d’API, mais C++ mérite aussi d’être reconnu
      C’est un très bon langage, surtout si l’on vient de langages web comme JavaScript non TypeScript ou PHP
    • Dans le cas d’une vieille base de code ayant évolué pendant 20 à 30 ans, ou non maintenue par des personnes compétentes, aucun autre langage qui ne serait pas horrible ne me vient à l’esprit
      En fait, parmi plusieurs possibilités auxquelles je peux penser, comme C, Java ou Fortran, je crois que je préférerais C++
      L’exception pourrait être C#, mais je ne sais pas s’il est assez ancien pour entrer dans cette catégorie

  • Contrairement à ce qu’on dit parfois — que C++ aurait désormais des expressions régulières intégrées et plutôt bonnes —, il est difficile de dire que std::regex est bon.
    Comme ses performances sont mauvaises et que son support d’Unicode est insuffisant, il vaut généralement mieux l’éviter.

    • Même le linter utilisé dans mon entreprise impose de ne pas utiliser std::regex.
    • Je me demande s’il existe un problème dans la spécification qui entraîne cette perte de performances.

  • J’ai appris C++ et je l’ai même apprécié, mais je ne suis jamais allé très loin.
    J’ai toujours préféré C, et il existe de nombreuses bases de code de tout premier ordre à lire pour mieux l’apprendre, comme le moteur de jeu Dune ou des utilitaires Unix.
    Récemment, après avoir un peu touché à Rust, je ne vois plus vraiment de raison forte d’utiliser C++.
    La combinaison d’un système de types puissant inspiré de la programmation fonctionnelle et des performances semble difficile à battre, presque comme un langage parfait.
    Cela dit, il y a évidemment des raisons liées au legacy pour lesquelles il faut encore utiliser C++.
    Peut-être les moteurs de jeu, la programmation embarquée ou d’autres formes de couplage avec l’existant.

    • Au travail, je passe de C++ à Rust, et honnêtement, en C++20/23 moderne, beaucoup de points douloureux sont corrigés en copiant plus ou moins Rust.
      Une nouvelle base de code C++ peut être rendue assez propre.
      Mais à ce stade, je ne comprends pas bien pourquoi on créerait un nouveau logiciel en C++.
      Les aspects pénibles de C++ sont nombreux.
      La gestion des bibliothèques/paquets n’est pas standardisée, les en-têtes sont de la duplication de code, et la bibliothèque standard dépend de l’implémentation tout en étant presque illisible.
      La norme comporte des comportements étranges, les gens s’appuient sur du comportement indéfini sans le savoir, il y a des problèmes d’utilisation avant allocation, et des fuites mémoire apparaissent subtilement à cause de problèmes de propriété et de compteurs de références incorrects.
      Il faut rendre tout const au lieu d’en faire le comportement par défaut, vérifier les exceptions de tout ce qu’on appelle pour garantir noexcept, et les erreurs pendant les opérations de la bibliothèque standard sont difficiles à lire.
      Le code fortement orienté objet est, en pratique, de la dette technique.
      Le LSP de C++ ne fonctionne pas de manière structurelle comme celui de Rust, qui examine l’arbre syntaxique abstrait pour trouver les définitions, si bien que la navigation et la compréhension de la base de code sont plus lentes.
      Rust prend explicitement en charge nostd comme fonctionnalité de première classe, alors qu’en C++ il faut des flags propres au compilateur pour désactiver la bibliothèque standard, et il est difficile de vérifier qu’on l’a fait correctement.
      C’est pourquoi l’argument de l’embarqué pour justifier C++ me convainc peu.
      Rust a aussi des moteurs de jeu comme bevy, même s’ils sont encore récents, et on peut aussi intégrer Rust au scripting de Godot si on le souhaite.
      L’audio bas niveau est tout aussi simple en Rust, avec une gestion multiplateforme possible via une seule crate.
      Globalement, je pense que le cœur du sujet, c’est le code legacy et la réticence au changement.
    • Le legacy est immense à de nombreux niveaux, pas seulement pour les applications écrites en C++.
      Cela inclut le nombre d’utilisateurs, les connaissances et ressources publiées et disponibles, les livres, cours, blogs, articles, vidéos, bibliothèques logicielles, ainsi que la forte compatibilité avec C, qui est lui-même un autre langage énorme.
      Pour quelqu’un qui est dans ce domaine depuis plus de quelques années, c’est presque du bon sens général dans l’industrie du logiciel.
      Je n’ai jamais beaucoup utilisé C++, donc je ne peux même pas vraiment me considérer comme un vrai débutant, mais j’ai déjà acheté et lu des classiques sur C++ de Bjarne Stroustrup, le créateur du langage, de Scott Meyers, etc., et je les ai compris dans une certaine mesure.
      En revanche, j’ai beaucoup utilisé C en production pendant des années, y compris pour des produits commerciaux réussis.
      https://www.stroustrup.com/applications.html
      https://www.stroustrup.com
      https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
      https://en.m.wikipedia.org/wiki/Scott_Meyers
    • C++ a du sens quand on a besoin d’une faible latence, mais qu’on ne se soucie pas tant que ça de la correction.
      C’est pourquoi je pense que le développement de jeux sera le domaine qui restera le plus longtemps en C++.
      Si le jeu plante avec une erreur de segmentation chez 0,001 % des utilisateurs, on a tendance à dire : et alors ?
    • Le trading à haute fréquence est aussi une possibilité.