08.10.2026 · Signal Titans Editorial
Bjarne Stroustrup a refusé de choisir entre abstraction et vitesse
Lorsque Bjarne Stroustrup arrive aux Bell Labs en 1979, il apporte avec lui un problème que les ingénieurs logiciels connaissent encore très bien : le modèle de programmation qui rend un système plus compréhensible n’est pas forcément celui qui permet de l’exécuter assez vite. Il avait utilisé Simula pour des travaux sur les systèmes distribués et appréciait ses classes et sa capacité à structurer des programmes complexes. Mais il voulait aussi conserver l’efficacité, la portabilité et le contrôle proche de la machine offerts par C. Plutôt que d’accepter ce compromis, il lança une expérience d’abord appelée « C with Classes ».
La contrainte est venue avant le langage
Stroustrup n’a pas commencé avec un manifeste visant à remplacer C. Son problème concret concernait la distribution de services de système d’exploitation sur un réseau. La question était simple à formuler mais difficile à résoudre : comment décrire un système complexe avec de meilleures abstractions sans payer une pénalité de performance qui rendrait le résultat inutilisable pour du logiciel système ? C possédait déjà ses compilateurs, ses programmeurs et une culture de l’efficacité. Simula offrait une organisation plus expressive. Le nouveau langage devait fonctionner avec les deux.
C’est pourquoi résumer C++ à « C avec de l’orienté objet » masque l’essentiel. Dans ses propres récits, Stroustrup revient sur un objectif plus profond : écrire des programmes à la fois efficaces et élégants. Compatibilité, abstractions sans coût inutile et implémentation réaliste étaient des contraintes de conception dès le départ.
« C with Classes » était un pont praticable
La première implémentation utilisait un préprocesseur traduisant les nouvelles constructions de classes en C. Stroustrup écrivit ensuite Cfront, un front-end de compilateur plus complet qui effectuait ses propres vérifications syntaxiques et sémantiques avant de produire du C. Cette approche permettait d’utiliser l’expérience dans l’écosystème existant des Bell Labs et de la tester sur de vrais projets, sans reconstruire immédiatement toute l’infrastructure de compilation.
Au début des années 1980, la communauté d’utilisateurs avait suffisamment grandi pour que maintenir « C with Classes » comme outil de recherche personnel devienne difficile. Stroustrup expliquera plus tard qu’il avait le choix entre arrêter l’expérience ou la transformer en un langage plus flexible et expressif. Il choisit la seconde voie. Le nom C++ apparut durant cette période, et la première version commerciale sortit en 1985, la même année que la première édition de The C++ Programming Language.
L’abstraction sans quitter la machine
C++ a ajouté un typage plus strict, des classes, des constructeurs, la surcharge d’opérateurs, des fonctions virtuelles puis, plus tard, des templates et une vaste bibliothèque standard. Mais l’idée la plus durable se trouve sous ces fonctionnalités : un programmeur devrait pouvoir construire des abstractions de haut niveau qui se traduisent efficacement sur le matériel. Une abstraction ne devrait pas imposer un coût caché simplement parce qu’elle est pratique. Cette philosophie a contribué à l’adoption de C++ dans les systèmes, les graphismes, le jeu vidéo, la finance, le calcul scientifique et d’autres domaines où structure et performance comptent ensemble.
Ce contrat a un prix. C++ a accumulé de la complexité parce qu’il cherchait à préserver l’ancien code, accueillir de nouveaux styles de programmation et rester adapté au travail bas niveau. Les critiques sur sa taille et sa difficulté sont réelles. Mais elles sont liées à la même décision historique qui lui a donné sa longévité : C++ a été conçu pour entrer dans un monde existant, pas pour demander à ce monde de repartir de zéro.
La normalisation a changé la propriété du langage
Quand C++ s’est diffusé au-delà des Bell Labs, aucune implémentation unique ne pouvait continuer à le définir seule. Le travail de normalisation commença à la fin des années 1980 et le premier standard ISO fut ratifié en 1998. Le langage passa alors à une gouvernance fondée sur un comité international, plusieurs compilateurs, des auteurs de bibliothèques et une très vaste communauté. Stroustrup resta influent, mais C++ devint plus grand que la feuille de route d’un seul concepteur.
Cette évolution explique pourquoi les changements modernes sont souvent des négociations. Toute nouvelle capacité doit coexister avec des décennies de code et des usages allant des systèmes embarqués aux grands services serveurs. Comparé à un langage neuf, le processus peut sembler conservateur. En réalité, la continuité fait partie du problème d’ingénierie.
La leçon durable : ne pas choisir trop tôt
En 2018, la National Academy of Engineering a décerné à Stroustrup le Charles Stark Draper Prize pour avoir conceptualisé et développé C++. La récompense mesure l’impact, mais la leçon la plus utile pour les programmeurs reste la contrainte d’origine. Stroustrup n’a pas accepté l’idée que lisibilité des abstractions et efficacité de la machine devaient vivre dans des langages séparés.
Aujourd’hui, les réponses à cette tension sont nombreuses : runtimes gérés, systèmes d’ownership, compilation JIT, abstractions fonctionnelles, langages bas niveau plus sûrs et accélérateurs spécialisés. C++ n’est ni la seule réponse ni toujours la plus simple. Son importance historique vient d’avoir montré que la conception d’un langage peut chercher à conserver plusieurs contraintes en même temps. Parfois, l’innovation qui dure n’est pas une fonctionnalité particulière, mais le refus d’abandonner une partie du compromis avant d’avoir réellement essayé de l’ingénier.
SIGNAL TITANS.jpg){kind=link}