10 points par GN⁺ 2024-11-26 | 3 commentaires | Partager sur WhatsApp
  • Le rêve d’un C++ unique, sans dialectes, semble avoir disparu depuis longtemps
  • De nombreux débats agitent l’avenir du C++ sur Reddit, sur ce site web orange (HN), ainsi que lors des réunions officielles du comité de normalisation du C++

État actuel du C++

  • Le groupe de travail sur l’évolution du C++ (EWG) a convenu d’adopter P3466 R0.
    • Maintien de la compatibilité de liaison avec le C et les anciennes versions du C++ sans rupture d’ABI (interface binaire d’application).
    • N’utilise pas de « annotations virales ».
    • S’accroche à des objectifs contradictoires : l’absence de rupture d’ABI et le principe de zero overhead.
  • Le gouvernement américain recommande d’arrêter d’utiliser le C++.
    • Plusieurs organismes, dont la CISA, la NSA et la Maison-Blanche, ont publié des alertes contre l’usage de langages non sûrs en mémoire.
  • Les grandes entreprises technologiques adoptent Rust.
    • Microsoft, Google et AWS utilisent Rust.
    • Google a même développé des outils d’interopérabilité C++/Rust
  • Conflits internes au sein de la communauté C++
    • Herb Sutter a quitté Microsoft, et des informations circulent selon lesquelles MSVC avance lentement sur l’implémentation des fonctionnalités de C++23.
    • Google réduit sa participation au processus de développement du C++ et développe son propre successeur au C++.
    • Manque de confiance dans le processus actuel du comité de normalisation du C++
    • La fonctionnalité des modules reste inachevée
    • Les « profils de sécurité (‘Safety Profiles’) » se trouvent dans une situation étrange

Les deux cultures du C++

  • Le groupe moderne, avec outils automatisés
    • Les grandes entreprises technologiques comme Google en sont les principaux exemples
    • Utilise les standards récents du C++ (C++17 et au-delà), avec un support d’outils automatisés de build et de test
    • Investit dans le maintien de la qualité du code et modernise en continu sa base de code
  • Le groupe du C++ legacy
    • Bases de code exploitées dans des environnements et avec des outils anciens
    • Fonctionnent parfois sans code source, ou avec des systèmes de build obsolètes
    • Coûts de maintenance élevés et fortes barrières à la modernisation
  • La principale différence réside dans les outils et les processus
    • Le groupe C++ moderne s’appuie sur des systèmes de build intégrés et sur des outils comme les analyseurs statiques, les formatters et les linters
    • Le groupe legacy souffre d’une faible efficacité opérationnelle en raison de l’absence de ces outils et processus

Résultats et impacts

  • Profils de sécurité
    • Vise à renforcer la sûreté sans modifier le code legacy existant
    • Se concentre davantage sur la préservation du code existant que sur les besoins du C++ moderne
  • Modules
    • Conçus pour permettre d’importer simplement des fichiers d’en-tête sous forme de modules
    • Pensés en tenant compte de la compatibilité avec le code legacy
  • Fragmentation de la communauté C++
    • L’écart entre les besoins des groupes moderne et legacy intensifie les tensions dans la communauté
    • L’approche conservatrice du comité de normalisation du C++ apparaît comme une tentative d’atténuer ces conflits

Point de vue alternatif

  • Des idées alternatives comme Safe C++ ne sont pas bien accueillies dans la communauté
  • Il existe aussi des critiques selon lesquelles certains membres du comité de normalisation résistent au changement par attachement à des critères esthétiques personnels

3 commentaires

 
aer0700 2024-11-27

Rust n’a pas encore d’écosystème pour le développement GUI, donc je ne peux pas vraiment l’adopter pour l’instant.
Il faudrait qu’un bon framework GUI pour Rust voie le jour...

 
ndrgrd 2024-11-26

Je ne sais pas vraiment si Rust peut remplacer C++, mais
il est vrai qu’on voit à peine de nouveaux projets C++...
Le comité C++ semble avoir décidé qu’il valait mieux privilégier ses valeurs fondamentales plutôt qu’une mue profonde.

 
GN⁺ 2024-11-26
Avis sur Hacker News
  • Le code C++ de Google ne fonctionne souvent pas avec les versions récentes, et les développeurs n’ont bien souvent aucune volonté de le corriger. Cela tient au fait que le code de Google reste coincé à mi-chemin entre l’ancien et le moderne

    • Le code C++ de Google peut subir des corruptions mémoire à cause des machines à états et des pointeurs faibles gérés manuellement
    • Voit d’un bon œil le départ de Google de l’écosystème C++
    • Pense que l’intérêt de Google pour l’écosystème Rust ne sera pas positif
  • Conseille aux personnes travaillant sur le standard C++ de soutenir l’orientation actuelle du C++ et d’ignorer le bruit en ligne sur l’avenir du langage

    • Recommande aux personnes qui veulent une vérification statique des durées de vie d’utiliser Rust
    • Suggère aux sous-traitants gouvernementaux d’utiliser Rust
    • Affirme que le processus de développement C++ existant fonctionne bien
  • Affirme que les seuls groupes qui utilisent encore C++ seront ceux qui ont des bases de code legacy trop vastes pour être refactorisées

    • D’autres groupes qui ont perdu confiance en WG21 migrent vers de nouveaux langages
    • Mentionne que Herb Sutter a dit qu’ajouter des annotations de durée de vie à C++ créerait une « bretelle de sortie » vers d’autres langages
  • Estime que le système d’éditions de Rust fonctionne très bien

    • Suggère que si un tel système était introduit en C++, malgré des limites aux frontières des modules, cela pourrait être une manière de satisfaire les deux camps
  • S’inquiète du fait que le départ de Herb Sutter de Microsoft aura un impact négatif pour Microsoft

    • Estime que Herb a piloté l’adoption du standard C++ et œuvré pour une meilleure vision de l’avenir
    • Mentionne que std::span, proposition de Microsoft, a été adopté sans vérification des bornes, et affirme que les efforts de Herb étaient nécessaires
  • Souligne que les tests automatisés sont l’élément principal qui distingue les deux camps

    • Explique que, dans une application C++ legacy, sans tests automatisés, les modifications de code risquent de casser l’application
    • Avertit qu’en raison de la nature du C++, même des changements de code apparemment inoffensifs peuvent provoquer des problèmes
  • Affirme que l’absence de modules est le principal facteur qui a réduit l’attrait du C++

    • Estime que si les modules avaient existé, une communauté C++ aurait pu se former
  • Compare Herb Sutter, habile pour obtenir des compromis, à Google, qui a poussé son propre agenda

  • Mentionne que les clients avec de très grandes bases de code ne veulent pas modifier ne serait-ce que 1 % de leur code pour satisfaire à des règles strictes

    • Affirme que de nombreuses entreprises consacrent du temps à la mise à niveau vers les nouveaux standards
  • Explique qu’il existe aussi plusieurs camps en Python et en Javascript/Node/Typescript

    • Estime que Rust a essayé d’éviter ces divisions, mais que cela a rendu la courbe d’apprentissage plus difficile
    • Mentionne que Go a essayé d’éviter les divisions et d’être largement adopté, mais a finalement dû introduire les génériques