Propositions d'évolution C++ : ères, standards réalistes et exceptions repensées
Les développeurs C++ jonglent avec trois versions du langage : celle décrite dans la norme mais indisponible ; celle expérimentale des compilateurs de pointe ; et la vraie, celle des versions largement utilisées. Cet écart entre théorie et pratique doit être comblé. La proposition : une fois une fonctionnalité approuvée, la transférer dans une spécification technique pour son implémentation par les compilateurs. Elle n'intègre la norme complète qu'après un support dans au moins deux compilateurs majeurs.
Cette approche révèle les problèmes lors de l'implémentation, permet des ajustements sans modifier la norme, et garantit que les fonctionnalités sont effectivement disponibles dans les compilateurs au moment de la publication de la norme. Les expérimentateurs accèdent aux nouveautés dès leur arrivée dans GCC ou Clang.
Mécanisme des ères pour se débarrasser de la compatibilité legacy
Introduire des « ères » en haut des fichiers .cpp déclarerait la version de C++ pour ce module. Cela permettrait d'éliminer des décennies d'accumulation de saletés : conversions automatiques de types numériques, pièges des comparaisons signed/unsigned, dégradations implicites de tableaux en pointeurs, et multiples syntaxes d'initialisation.
Avantages clés :
- Mélanger des fichiers d'ères différentes dans un projet sans réécrire le code legacy.
- Transpiler du code moderne vers des normes plus anciennes pour préserver la compatibilité ABI.
- Faire évoluer un C++ amélioré sans que la compatibilité arrière avec C ne le freine.
Les ères empêchent le langage de gonfler en monstre sous le poids des ornières historiques.
Repenser les exceptions en C++
Les exceptions en C++ ont été un fiasco des années 1980 : coûteuses, imprévisibles, et bannies dans la moitié des projets. Des alternatives comme std::expected ne résolvent pas les problèmes de fiabilité. Il faut des exceptions à coût nul intégrées aux ères : les nouvelles seulement dans les fichiers d'ères récentes.
Mélanger code ancien et nouveau pose des casse-têtes d'intégration, mais le statu quo est intenable. La communauté divisée entre « avec exceptions » et « sans » freine le progrès.
Points clés à retenir
- Les normes doivent codifier des fonctionnalités implémentées, pas devancer via des spécifications techniques.
- Les ères permettent de mixer code legacy et moderne tout en purgeant le nouveau des erreurs historiques.
- De nouvelles exceptions à coût nul se déploient par ère, réduisant les surcoûts et améliorant la prévisibilité.
- Sans ces changements, C++ risque le sort de PL/I : complexité explosive sans gains.
- Le comité doit prioriser les mécanismes stratégiques sur les détails tactiques.
Conclusion et perspectives
Pour que C++ prospère encore 40 ans, il faut des virages audacieux : normes pragmatiques, ères pour l'évolution, et reboot des exceptions. Cela unifie l'écosystème, simplifie le nouveau code, et préserve l'ancien. Le comité doit passer des déclarations à la documentation des pratiques réelles, laissant le langage s'adapter sans fardeaux du passé.
— Editorial Team
Aucun commentaire pour le moment.