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 :

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