
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 :

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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.