IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Normalisation C++ Discussion :

La communauté C++ est divisée entre défenseurs du « C++ moderne » et les défenseurs du « C++ hérité »


Sujet :

Normalisation C++

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Juin 2023
    Messages
    970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2023
    Messages : 970
    Points : 17 248
    Points
    17 248
    Par défaut La communauté C++ est divisée entre défenseurs du « C++ moderne » et les défenseurs du « C++ hérité »
    Les deux factions du C++ : la communauté est divisée entre ceux qui souhaitent un C++ moderne avec un meilleur outillage intégré et ceux qui veulent conserver le langage hérité

    La notion d'un C++ unique, sans dialecte et unifié, semble être morte depuis des années. Au moins deux factions se font face aujourd'hui sur les questions liées à l'évolution du langage. D'un côté, on distingue les utilisateurs qui souhaitent voir C++ évoluer vers un langage « relativement modernes » avec des outils facilitant le travail, tels qu'un analyseur statique, un formateur, linter, etc. De l'autre côté, on retrouve le groupe des utilisateurs qui souhaitent préserver le langage hérité qui assure une rétrocompatibilité avec l'ABI (Application Binary Interface) et qui s'opposent à l'idée d'ajouter une nouvelle couche de complexité à C++.

    Faire évoluer le langage C++ en renforçant l'outillage et la sécurité

    Les questions liées à l'évolution du langage C++ font l'objet d'un débat intense depuis de nombreuses années. Ce débat s'est intensifié avec l'avènement de langages jugés plus sécurisés et plus prometteurs que C++, tels que Rust et Go. Ces langages « modernes » s'efforcent de dépasser les limites des langages plus anciens comme C et C++ en améliorant la sécurité, l'expressivité, la prise en charge de la concurrence et en renforçant l'outillage des développeurs.


    Ces langages visent également à simplifier les tâches de programmation complexes et à promouvoir de meilleures pratiques d'ingénierie logicielle grâce à des fonctionnalités et des écosystèmes linguistiques avancés. Ces concepts attirent de plus en plus de développeurs et d'entreprises technologiques. Ainsi, bien que C++ excelle en matière de performances, de programmation de bas niveau et de compatibilité multiplateforme, ils souhaitent que le langage évolue.

    Les entreprises technologiques relativement modernes et compétentes qui utilisent C++ et qui comprennent que leur code est un atout entrent dans cette catégorie. Ces dernières années, l'on a assisté notamment à une ruée des entreprises technologiques et de certains gouvernements vers Rust :

    • Rust en voie d'être intégré dans le noyau Linux avec le projet Rust-for-Linux ;
    • Amazon a commencé à utiliser le lange Rust ;
    • Microsoft est apparemment en train de réécrire les bibliothèques de base en Rust ;
    • Google semble s'engager en faveur de Rust et a commencé à travailler sur un outil d'interopérabilité bidirectionnelle C++/Rust ;
    • le gouvernement américain appelle les développeurs à adopter des langages offrant une sécurité de la mémoire, tels que Rust ;
    • Linus Torvalds a laissé entendre que l'intégration de Rust dans le noyau Linux peut aider à corriger des erreurs commises en C ;
    • etc.


    Herb Sutter, expert en C++ et président du comité de normalisation du langage, vient de quitter Microsoft après 22 années de collaboration et a déclaré que la prochaine version de C++ 26 sera « la plus importante depuis C++ 11 ». L'annonce de Herb Sutter a suscité l’enthousiasme et l’impatience de nombreux développeurs, tant C++11 avait introduit des avancées majeures (smart pointers, constexpr, etc.) et modernisé le langage de manière significative.

    En 2022, Herb Sutter a présenté à la communauté un projet appelé « Cppfront ». Le projet propose une nouvelle syntaxe C++ censée être dix fois plus simple que la syntaxe actuelle, plus sûre et avec le même niveau de support d’outils dont bénéficient les autres langages. Sa proposition a suscité un débat intense dans la communauté et des comparaisons avec projets similaires, tels que le langage Carbon présenté comme un successeur potentiel de C++.

    Préservation de la rétrocompatibilité avec l'ABI : une source de conflits

    Si de nombreux utilisateurs de C++ veulent faire évoluer le langage vers quelque chose de plus moderne avec un meilleur outillage intégré, des rapports ont souligné que d'autres développeurs et entreprises n'épousent pas cette idée. Selon eux, les nouvelles fonctionnalités ajoutent de la complexité, augmentent la courbe d'apprentissage de C++ et rendent le langage plus difficile à appréhender. Ils veulent préserver la compatibilité binaire avec le code hérité.


    Qui sont ces utilisateurs de C++ ? « Toutes les anciennes entreprises où les gens se battent encore pour savoir comment indenter leur code, et où un jeune ingénieur supplie la direction de lui permettre de mettre en place un linter », a écrit l'ingénieur logicielle "Mond" dans un récent billet de blogue. Selon Mond, le groupe qui a raison dans ce débat de longue date n'a pas vraiment d'importance. Cela dit, il souligne différence importance entre les deux groupes :

    Citation Envoyé par Mond

    L'un de ces groupes sera capable de gérer une migration avec une certaine élégance, et c'est le groupe qui est capable de construire sa pile C++ à partir de sources versionnées, et non le groupe qui utilise encore d'anciennes bibliothèques préconstruites datant de 1998.

    Cette capacité à construire l'ensemble de la pile de dépendances à partir des sources versionnées (de préférence avec des tests automatisés) est probablement la ligne de démarcation la plus critique entre les deux camps.

    Il y a un fossé énorme et croissant entre ces deux factions (meilleur outillage, peut construire sans effort à partir des sources vs. mauvais outillage, ne peut pas construire à partir des sources), et honnêtement je ne vois pas ce fossé se refermer de sitôt.
    Selon l'équipe Carbon, les concepteurs de C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est considérée comme un autre problème hérité. Les critiques accusent le comité C++ et le processus d'évolution d'être orientés vers la normalisation plutôt que la conception, lents et souvent incapables de prendre des décisions.

    Mond suggère que Google a manifestement perdu confiance dans le processus depuis le vote sur l'ABI (Application Binary Interface). « Il ne s'agit pas d'une perte de confiance dans le langage lui-même, Google possède l'une des plus grandes bases de code C++ au monde, et il lui a rendu d'incroyables services. Il s'agit d'une perte de confiance dans la capacité du langage à évoluer au fur et à mesure que la pression monte sous différents angles », a-t-il écrit.

    Selon Mond, ces pressions comprennent les réglementations gouvernementales potentielles, langages concurrents, désir de meilleures performances et garanties de sécurité de la part d'acteurs clés, etc. Il pense que le comité C++ semble « assez engagé » à préserver la compatibilité ascendante, quel qu'en soit le coût.

    Les critiques à l'égard du comité de normalisation du langage C++

    Le comité de normalisation de C++ fait l'objet de critiques de la part des utilisateurs désireux de voir le langage se moderniser rapidement avec un meilleur outillage intégré. Pour les critiques, les nouvelles fonctionnalités visent à réduire les erreurs courantes et à simplifier la maintenance à long terme. Toutefois, selon eux, le comité C++ ralentit l'évolution du langage en maintenant l'accent sur la rétrocompatibilité avec l'ABI. Comme l'a souligné Herb Sutter :

    « Nous devons minimiser la nécessité de modifier le code existant. En ce qui concerne l'adoption dans le code existant, des décennies d'expérience ont constamment montré que la plupart des clients possédant de grandes bases de code ne peuvent et ne veulent pas modifier ne serait-ce que 1 % de leur base de code afin de satisfaire aux règles de rigueur, pas même pour des raisons de sécurité, à moins que des exigences réglementaires ne les y contraignent ».

    Selon les critiques du comité C++, cette contrainte ralentit l'évolution du lange vers quelque chose de plus sûre et plus facile à utiliser. Bien que Mond ne critique pas le comité C++, il souligne : « bien sûr, tout le monde aime les nouvelles fonctionnalités qui peuvent être intégrées et apporter des améliorations sans nécessiter la modification de l'ancien code. Mais il est clair que ces fonctionnalités sont conçues (avant tout) dans l'optique d'un "C++ hérité" ».

    Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.

    La feuille de route actuelle de Carbon vise à terminer la version 0.1 du langage cette année, la 0.2 en 2023 et la version 1.0 en 2024 ou 2025. Par ailleurs, les projets Cppfront et Carbon sont des exemples d’une longue liste dans laquelle on retrouve d’autres initiatives comme Circle, Val et Dlang.

    Impacts potentiels de cette division sur la communauté C++

    Dans le débat intense sur l'attitude à adopter dans le développement du langage C++, l'on observe deux grands publics qui se font face. Le premier est celui du C++ moderne, et le second est celui du C++ hérité. Ces deux camps ne sont pas du tout d'accord et de nombreux articles sont rédigés en tenant compte des besoins d'un groupe spécifique. Cela conduit au fait que de nombreuses personnes se parlent à tort et à travers lors des débats sur le sujet.

    « Bien sûr, on peut aussi se demander si certains membres du comité de normalisation du C++ ne sont pas tout simplement très, très têtus, et s'accrochent à des bouts de ficelle pour empêcher une évolution qu'ils désapprouvent personnellement sur le plan esthétique », souligne Mond dans son billet de blogue.

    Source : billet de blogue

    Et vous ?

    Quel est votre avis sur le sujet ?
    Que pensez-vous des deux factions qui s'opposent dans le débat sur l'évolution du C++ ?
    Êtes-vous de ceux qui souhaitent une évolution vers un C++ moderne avec un meilleur outillage intégré ?
    Que pensez-vous de la préservation de la rétrocompatibilité avec l'ABI ?
    Considérez-vous également que la préservation de la rétrocompatibilité avec l'ABI ralentit l'évolution du langage C++ ?
    Que pensez-vous de la position du comité de normalisation du langage C++ sur cette question ?
    Les projets tels que Carbon, Cppfront, Circle, Val et Dlang pourraient-ils faire de l'ombre à C++ à l'avenir ? Pourquoi ?

    Voir aussi

    C++ vs Rust : une comparaison pratique de la vitesse de compilation et de test des deux langages de programmation par Matthew Glazar, ingénieur en génie logiciel

    Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs sur les besoins en termes d'évolution du langage et les comparaisons avec des projets similaires

    Existe-t-il un consensus au sein de l'industrie sur l'abandon de C/C++ ? Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire

  2. #2
    Membre averti
    Homme Profil pro
    Architecte réseau
    Inscrit en
    Février 2024
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Architecte réseau

    Informations forums :
    Inscription : Février 2024
    Messages : 127
    Points : 392
    Points
    392
    Par défaut
    Je ne comprends pas bien pourquoi défendre le langage hérité. La library standard intègre pas mal de nouvelles fonctionnalités dans la dernière version ce qui limite l'usage de Boost. Et les shared_ptr simplifient quand-même pas mal les choses.

    On aimerait par contre que les fonctions historiques acceptent plus de surcharges, genre qu'il soit possible de travailler avec les string au lieu de se taper des char* afin de s'éviter du verbiage et/ou des lignes de code supplémentaires.

  3. #3
    Membre émérite Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 048
    Points : 2 258
    Points
    2 258
    Par défaut
    Ça va faire 15 ans que je code en C++, et clairement je fais partie du groupe de "faut tout péter".
    La rétrocompatibilité ne devrait pas avoir lieu sur des versions majeurs.
    Le code legacy sur lequel j'ai travaillé est toujours compilé avec une version spécifique d'un compilateur, et JAMAIS il n'a été autorisé de travailler avec des versions de compilateur autre que celle recommandé par le projet. Le nombre de fois où j'ai dû trouver un GCC 4.8....
    Les améliorations comme les modules sont certes présentes mais aucun projet nouveau que j'ai pu croiser ne les utilisent pour la simple raison que c'est le bordel entre GCC clang et msvc qui font tous leur tambouille et c'est blindé de bug.

    J'ai appris le Rust, et même si il a des défauts à mon sens ( pas de POO intégré au langage, la relative lenteur de création de prototype de logiciel où l'on s'en fou de la sécurité mémoire car on doit aller vite en itération/modification de design et en rust on ne peut pas modifier un design rapidement, pas aussi vite qu'en C++).

    J'aime de tout mon coeur le C++ et même si il ne vas pas disparaitre, le nombre de personne qui vont vouloir continuer à supporter ces lourdeurs de syntaxe vont être de moins en moins nombreuses et on va se retrouver avec des vieux grisonnant aigris qui vous diront "de mon temps c'était mieux avant faut rien changer".
    Qui va supporter la base de Google dans 10-15 ans? Les jeunes qui sortent de l'école ?
    On va se retrouver comme Cobol qui est partout dans le secteurs bancaires.

    Faites un C++ avec 1 seul compilateur, 1 linter , 1 outils de couverture de code, 1 outil de test, faites des versions qui casse la rétrocompatibilité et faite en sortent que les développeurs n'en ai pas marre de coder en C++ et qui font de la me**e parce que c'est chiant, l'existant est déjà buggé et qu'un nouvel arrivant met 1 semaine à compiler un projet de A à Z sur sa machine et qu'il arrivent à le lancer sans crash pour x ou y raison.

    Faite un "cargo new projet_c++"

    J'aime le C++ mais après 15 ans je commence à regarder la voisine car le C++ ne me fait plus rêver mais il me donne du boulot par contre et ça c'est cool
    Homer J. Simpson


Discussions similaires

  1. tester si un chiffre est compris entre deux
    Par yos dans le forum XSL/XSLT/XPATH
    Réponses: 2
    Dernier message: 06/07/2007, 16h42
  2. [RegEx] Savoir si un texte est contenu entre deux caractères
    Par CodeMikiman dans le forum Langage
    Réponses: 5
    Dernier message: 04/02/2007, 12h25
  3. Réponses: 6
    Dernier message: 09/11/2006, 11h29
  4. [VB]Enlever 1 jour à une date si heure est comprise entre...
    Par bb62 dans le forum VB 6 et antérieur
    Réponses: 17
    Dernier message: 20/01/2006, 15h48
  5. Faire une division entre deux chiffres?
    Par shun dans le forum Langage SQL
    Réponses: 9
    Dernier message: 09/09/2005, 17h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo