Philosophie de l'ingénierie : Bjarne Stroustrup, l'abstraction sans surcoût

Points clés

• L’abstraction sans surcoût. Stroustrup a conçu C++ pour mettre fin au faux choix entre un code clair et la vitesse du métal – la version expressive et la version optimisée à la main doivent compiler vers le même code machine.
• Le principe du surcoût nul. « Ce que vous n’utilisez pas, vous ne le payez pas ; ce que vous utilisez, vous ne pourriez pas l’écrire mieux à la main » est la règle que chaque fonctionnalité de C++ doit franchir.
• RAII rend la chose concrète. Lier la durée de vie d’une ressource à un objet sur la pile offre un nettoyage déterministe et sûr face aux exceptions, sans ramasse-miettes – un motif que Rust a ensuite repris presque intégralement.
• Ne rien laisser en dessous. C++ doit rester le langage de plus haut niveau ne laissant rien entre lui et le silicium, hormis l’assembleur, sinon un langage de plus bas niveau prendrait sa place.

Le principe

« Ce que vous n’utilisez pas, vous ne le payez pas. Et plus encore : ce que vous utilisez, vous ne pourriez pas l’écrire mieux à la main. » – Bjarne Stroustrup, le principe du surcoût nul¹

Cette phrase est la plus importante de toute la programmation système, et elle porte deux promesses. La première moitié affirme qu’une abstraction doit être gratuite au point de non-usage : touchez à une fonctionnalité et elle vous coûte quelque chose, ignorez-la et elle ne vous coûte rien – pas un octet de mémoire, pas un cycle d’exécution. La seconde moitié est la promesse la plus difficile : lorsque vous utilisez l’abstraction, le compilateur doit produire un code machine au moins aussi bon que celui qu’un programmeur compétent aurait écrit à la main pour cette tâche précise. Un vector qui ne vérifie aucune borne en mode release. Un pointeur intelligent qui compile vers un simple pointeur. Un itérateur qui s’évanouit dans une boucle brute. La clarté est gratuite.

La plupart des langages imposent un compromis. Vous obtenez la version expressive, de haut niveau, qui est lente, ou vous descendez vers la version rapide, de bas niveau, qui est illisible – et tout le métier se réduit alors à choisir quelle douleur accepter, et quel jour. Toute la carrière de Stroustrup est un refus de ce compromis. Il l’avait éprouvé personnellement : doctorant, il aimait les abstractions de Simula mais les trouvait trop lentes pour un travail réel, et il aimait la vitesse de BCPL mais le trouvait trop bas niveau pour y bâtir quoi que ce soit d’ampleur.² C++ existe parce qu’il a décidé que l’on ne devait pas avoir à choisir. L’efficacité et l’abstraction n’étaient pas des cadrans opposés à équilibrer ; elles étaient censées arriver ensemble, dans la même ligne de code.

Cette conviction est exactement celle qui sous-tend l’argument selon lequel la performance n’est pas une fonctionnalité que l’on ajoute mais une propriété que l’on échoue à conserver. Une abstraction à surcoût nul n’est pas une chose rapide bâtie au-dessus d’un langage lent. C’est une chose claire que le compilateur rabote jusqu’à obtenir exactement ce que vous auriez écrit à la main, de sorte que vous ne payez jamais pour la clarté. « J’aime que mon code soit élégant et efficace », a-t-il dit – et le mot qui compte est le et. Il déteste avoir à choisir entre les deux.³

Contexte

Bjarne Stroustrup est né le 30 décembre 1950 à Aarhus, au Danemark.⁴ Il a étudié les mathématiques et l’informatique à l’université d’Aarhus, puis est parti en Angleterre pour un doctorat au Computing Laboratory de l’université de Cambridge, qu’il a achevé en 1979. Sa thèse – « Communication and control in distributed computer systems » – portait sur la manière de répartir le travail d’un système d’exploitation à travers un réseau d’ordinateurs.⁴

Pour étudier ce problème, il lui fallait construire un simulateur, dont il écrivit la première version en Simula, le langage norvégien (conçu par Ole-Johan Dahl et Kristen Nygaard) qui avait fait découvrir au monde les classes et les objets. Stroustrup l’adorait. Les abstractions de classe de Simula lui permettaient d’organiser un programme vaste et complexe tel que le problème était organisé, et non tel que la machine l’était – et le programme était un plaisir à écrire et à modifier. Puis il a tenté de l’exécuter à grande échelle, et les abstractions se sont effondrées sous leur propre coût. L’implémentation était trop lente pour être pratique. Il réécrivit le simulateur en BCPL, un langage système dépouillé, et retrouva la vitesse – mais BCPL était si bas niveau que bâtir quoi que ce soit d’ampleur avec lui relevait du supplice.² Ce coup de fouet fut la blessure fondatrice. Il avait utilisé le langage expressif et l’avait payé en performance, puis utilisé le langage rapide et l’avait payé en tout le reste. Aucun n’était acceptable. Les deux moitiés auraient dû être possibles en même temps.

Il emporta ce grief aux Bell Labs, dans le New Jersey, en 1979, où il fit de nouveau face à un problème de systèmes distribués : analyser le trafic du noyau UNIX à travers un réseau. Se souvenant de Cambridge, il entreprit d’ajouter à C la puissance d’organisation de Simula – un langage déjà rapide et proche du matériel, le langage système d’UNIX – sans céder une once de la vitesse de C.⁴⁵ Il appela le résultat « C with Classes ». En 1983, son collègue Rick Mascitti suggéra le nom C++, l’opérateur d’incrémentation appliqué à C lui-même : le C suivant, en mieux d’un cran, la même machine en dessous.⁵

L’œuvre

De « C with Classes » à C++ : un meilleur C qui ne coûte rien

Le geste initial (1979-1983) fut délibérément modeste et parfaitement juste. Prendre C – déjà rapide, se projetant déjà directement sur le matériel, déjà le langage système auquel les gens faisaient confiance – et lui ajouter ce que Simula lui avait appris à désirer : les classes, un meilleur contrôle de type, l’abstraction de données.⁵ Et surtout, il les ajouta comme une couche que les programmeurs C n’avaient pas à payer. Un programme C restait un programme C++ valide. Une struct n’utilisant aucune des nouvelles fonctionnalités compilait vers les mêmes octets qu’auparavant. La nouvelle puissance était facultative, et l’utiliser ne coûtait que ce qu’aurait coûté le C équivalent écrit à la main. Voilà le principe du surcoût nul à l’état d’embryon, présent avant même qu’il ne lui ait donné un nom : ne pas taxer ceux qui n’utilisent pas la fonctionnalité, et ne pas laisser la fonctionnalité engendrer un code pire que celui qu’ils auraient écrit eux-mêmes.

Il documenta et stabilisa le langage dans The C++ Programming Language (1985), le livre qui le rendit largement accessible, puis passa des décennies à en défendre le cœur à travers la conception de chaque fonctionnalité ultérieure.⁴

Le principe du surcoût nul

Le principe du surcoût nul est l’idée porteuse, la règle à l’aune de laquelle chaque fonctionnalité de C++ se mesure. Stroustrup l’énonce en deux parties : « Ce que vous n’utilisez pas, vous ne le payez pas (en temps ou en espace) et plus encore : ce que vous utilisez, vous ne pourriez pas l’écrire mieux à la main. »¹ La première clause est une politique fiscale – aucune fonctionnalité ne peut imposer de coût à un code qui ne l’utilise pas. La seconde est une exigence de qualité – une fonctionnalité que vous utilisez doit compiler vers un code pas pire que celui qu’un programmeur soigneux aurait produit à la main pour cette tâche précise. Les templates, constexpr, la sémantique de déplacement, ainsi que les conteneurs et algorithmes de la bibliothèque standard sont tous conçus pour l’honorer ; les deux exceptions célèbres, l’identification de type à l’exécution et les exceptions, sont précisément les deux fonctionnalités que les compilateurs offrent de désactiver par un interrupteur, parce qu’elles ploient la règle.⁶

La récompense est cette chose qui semble impossible jusqu’à ce que vous voyiez l’assembleur : la voie expressive et la voie optimisée à la main produisent le même code machine.

Cette identité – l’expressif et l’optimisé à la main s’effondrant en une seule sortie – est ce qui fait que le principe est moral autant que technique. Il retire à l’ingénieur son excuse habituelle. Si la clarté était réellement coûteuse, vous pourriez justifier d’écrire la version laide et rapide « parce qu’il faut que ce soit rapide ». Le pari de Stroustrup est que cette excuse est généralement un mensonge – qu’une abstraction bien conçue vous permet d’avoir la version lisible et la version rapide, parce qu’elles sont la même version. Le coût a été payé une seule fois, par le concepteur du langage, pour qu’il ne soit plus jamais payé par le programmeur.

RAII et les ressources déterministes

Le principe avait besoin d’un mécanisme pour la partie la plus désordonnée de la programmation système : les ressources que l’on doit acquérir puis libérer de façon fiable – mémoire, fichiers, verrous, sockets. Le ramasse-miettes répond à cela en renonçant au déterminisme : le nettoyage se produit un jour ou l’autre, selon le calendrier du collecteur, ce qui est intolérable pour un verrou ou un descripteur de fichier. La réponse de Stroustrup, qu’il a nommée RAII – Resource Acquisition Is Initialization – lie la durée de vie d’une ressource à la durée de vie d’un objet sur la pile.⁷ Vous acquérez la ressource dans un constructeur ; vous la libérez dans le destructeur ; et comme C++ garantit que le destructeur d’un objet sur la pile s’exécute à l’instant même où il quitte sa portée – normalement ou via une exception, dans l’ordre inverse de la construction – la ressource est libérée exactement quand elle doit l’être, de façon déterministe, sans collecteur et sans free manuel à oublier.⁷

RAII, c’est le surcoût nul rendu concret. L’appel du destructeur est un code que vous auriez de toute façon dû écrire à la main ; le langage garantit simplement que vous ne pouvez pas l’oublier. Vous obtenez un nettoyage automatique, sûr face aux exceptions et déterministe, et vous ne payez rien que vous n’auriez payé en codant le nettoyage à la main. C’est le motif de C++ que des langages ultérieurs, Rust au premier chef, reprendront presque intégralement.

La normalisation et « ne laisser aucune place à un langage de plus bas niveau »

Stroustrup ne garda pas C++ comme un projet personnel. Il le porta au comité de normalisation – ANSI à partir de 1989, ISO à partir de 1991 – et y siégea pendant des décennies, présidant l’Evolution Working Group, afin que C++ soit une norme stable et indépendante des éditeurs plutôt que le dialecte d’une seule entreprise.⁴ Et il donna au comité une règle constitutionnelle, tirée de ses principes de conception dans The Design and Evolution of C++ : « Ne laisser aucune place à un langage de plus bas niveau en dessous de C++ (hormis l’assembleur). »⁸ Le raisonnement est précis – si l’on pouvait écrire un code plus efficace dans un langage situé entre C++ et le métal nu, alors ce langage deviendrait le langage système de prédilection et C++ perdrait sa raison d’être.⁸ Pour rester viable, C++ doit conserver l’accès direct au matériel de C, son contrôle de la disposition des données, et ses types primitifs qui se projettent un à un sur la machine.⁸ Rien ne devrait s’intercaler entre l’abstraction et le silicium, hormis l’assembleur. Le principe du surcoût nul, énoncé comme une frontière concurrentielle : être le langage de plus haut niveau qui ne laisse pourtant rien sur la table.

La méthode

La méthode tient en un seul pari – la clarté et la vitesse sont une seule et même chose si l’on conçoit correctement l’abstraction – imposé comme un ensemble de règles strictes.

Mesurer chaque fonctionnalité à l’aune du surcoût nul. Aucune fonctionnalité ne peut taxer un code qui ne l’utilise pas, et aucune fonctionnalité ne peut engendrer un code pire que son équivalent écrit à la main. C’est la barrière que chaque ajout à C++ a dû franchir pendant quarante ans.¹⁶

Faire confiance au programmeur, et rester multi-paradigme. C++ prend en charge les styles procédural, orienté objet, générique et fonctionnel parce que Stroustrup a refusé de décider à votre place comment organiser votre problème. Le langage vous donne les outils et part du principe que vous connaissez votre domaine mieux que ne le connaît le concepteur du langage.⁶

Se projeter directement sur le matériel. Conserver la correspondance un à un de C entre les types primitifs, la disposition des données et la machine. L’abstraction repose sur le métal, et non au-dessus d’un environnement d’exécution qui le masque.⁸

Rendre le nettoyage déterministe, et non différé. RAII lie la durée de vie de la ressource à la durée de vie de l’objet, de sorte que la libération se produit à un instant connu, sûr face aux exceptions, sans ramasse-miettes et sans rien à penser à libérer.⁷

Le stabiliser au grand jour. Confier le langage à un comité de normalisation international plutôt que d’en être propriétaire, afin que C++ soit une norme publique durable qu’aucun éditeur isolé ne puisse scinder.⁴

Chaîne d’influence

Qui l’a façonné

Ole-Johan Dahl et Kristen Nygaard, via Simula. Simula a appris à Stroustrup à quoi sert l’abstraction – permettre à un programme d’être structuré tel que le problème est structuré – et sa lenteur lui a enseigné l’autre moitié de la leçon : qu’une abstraction ne vaut rien si l’on ne peut pas se permettre de l’utiliser. C++ est la tentative de conserver le don de Simula sans en payer le coût. (Influence directe et fondatrice)

BCPL, et la culture de la programmation système autour de C et d’UNIX. BCPL lui a donné la douleur inverse – la vitesse brute sans aucun moyen d’organiser quoi que ce soit d’ampleur – et C, le langage d’UNIX aux Bell Labs, lui a donné la fondation rapide et projetée sur le matériel pour bâtir C++ par-dessus plutôt qu’à sa place.²⁵ (Influence directe)

Les Bell Labs. La même institution qui produisit C et UNIX donna à Stroustrup le problème de systèmes distribués qui lança « C with Classes » et la culture de recherche qui lui permit de passer des années à peaufiner le langage. (Influence fondatrice)

Qui il a façonné

L’infrastructure du monde tourne sur son langage. Systèmes d’exploitation, navigateurs, bases de données, moteurs de jeu, compilateurs, systèmes de trading à haute fréquence, logiciel de vol des rovers martiens – le cœur critique en performance de l’informatique moderne est disproportionnellement écrit en C++. Le travail de peu d’ingénieurs est à ce point porteur.

Le mouvement des abstractions à coût nul. Le principe de Stroustrup, rebaptisé « zero-cost abstractions », est devenu un objectif fondateur explicite de Rust, qui a adopté RAII (sous la forme de l’ownership et de Drop), la destruction déterministe, et la règle voulant que les constructions de haut niveau compilent vers un code machine optimal. Des langages comme D et Carbon descendent de la même lignée. L’idée selon laquelle on ne devrait pas payer pour la clarté est aujourd’hui généralisée, et elle est la sienne.⁶

Le fil conducteur

John Carmack veut que la boucle interne fasse le moins de travail que la physique autorise – « la vitesse de la lumière, ça craint », la machine gouvernée par des limites dures, chaque cycle gaspillé étant un choix. Stroustrup tend à Carmack les outils pour écrire cette boucle de façon lisible : une abstraction à surcoût nul est la promesse que la version claire et la version la plus proche du métal sont le même code machine, de sorte que vous n’avez jamais à trancher. Là où Barbara Liskov a donné à l’abstraction sa théorie – l’abstraction de données, le contrat qu’un type doit à ses utilisateurs, la lignée Simula-vers-CLU du « vous devez programmer contre ce qu’une chose fait, et non contre la façon dont elle fonctionne » – Stroustrup a donné à cette théorie un corps dont l’exécution ne coûte rien. Et là où Alan Kay imaginait les objets comme de petits ordinateurs échangeant des messages, une conversation à liaison tardive et à l’exécution, Stroustrup a pris la route opposée vers le même mot : ses objets sont résolus à la compilation et se dissolvent en code machine brut, l’OOP comme outil d’organisation à surcoût nul plutôt que comme bus de messages vivant. Même vocabulaire, deux philosophies – l’une optimisant pour la souplesse, l’autre pour la facture à l’exécution. (Pont de série)

Ce que j’en retiens

La leçon que je garde, c’est que « expressif ou rapide » est presque toujours un faux choix qu’une mauvaise conception vous impose. Quand je me surprends à écrire la version laide « parce qu’il faut que ce soit rapide », le principe de Stroustrup est l’accusation : ce n’est pas une loi de l’informatique, c’est un échec à trouver l’abstraction qui compile d’elle-même vers la chose rapide. Le travail consiste à concevoir la version claire si bien que la machine en produise le code optimal – à payer le coût une seule fois, dans la conception, pour qu’il ne soit plus jamais payé dans chaque ligne qui l’utilise. C’est la même exigence que celle voulant que la qualité soit la seule variable : la question n’est jamais « puis-je me permettre de rendre ceci clair ? » mais « pourquoi mon abstraction fuit-elle au point que la clarté coûte quoi que ce soit ? »

Dans le monde où je construis aujourd’hui – agents, boucles d’outils, systèmes d’IA – la tentation est l’inverse du surcoût nul : empiler une surcouche sur une surcouche, consommer un appel de modèle pour masquer un chemin lent, laisser chaque abstraction commode ajouter en silence une latence que personne ne mesure. Le geste de Stroustrup consiste à exiger que l’interface commode compile vers l’interface efficace – que l’API propre et le chemin rapide soient le même chemin, le coût étant payé dans la conception du cadre d’agent plutôt que facturé à chaque appel qui le traverse. Cette conviction – que le goût est un système technique contre lequel on peut opposer une règle stricte, et non une vibe que l’on affirme – est le fil conducteur d’un simulateur de 1979 qui tournait trop lentement jusqu’à un cadre d’agent de 2026 qui ne le devrait pas.

FAQ

Quelle est la philosophie d’ingénierie de Bjarne Stroustrup ?

La conviction de Stroustrup est que l’on ne devrait jamais avoir à choisir entre un code expressif de haut niveau et la performance du métal. Il a bâti C++ sur le principe du surcoût nul : une fonctionnalité du langage ne doit rien coûter lorsque vous ne l’utilisez pas, et lorsque vous l’utilisez, elle doit compiler vers un code pas pire que celui que vous auriez écrit à la main pour cette tâche.¹ Il a associé cela à la confiance au programmeur (C++ est délibérément multi-paradigme), à la projection directe sur le matériel, à la gestion déterministe des ressources via RAII, et à la stabilisation du langage en tant que norme ISO ouverte plutôt qu’en tant que propriété.⁴⁶⁷

Qu’est-ce que le principe du surcoût nul ?

C’est la règle que Stroustrup énonce en deux parties : « Ce que vous n’utilisez pas, vous ne le payez pas (en temps ou en espace) et plus encore : ce que vous utilisez, vous ne pourriez pas l’écrire mieux à la main. »¹ La première moitié signifie qu’une fonctionnalité inutilisée n’impose aucun coût d’exécution ni de mémoire ; la seconde signifie qu’une fonctionnalité que vous utilisez engendre un code au moins aussi bon que celui qu’un programmeur compétent écrirait à la main. C’est la barrière que chaque fonctionnalité de C++ doit franchir. Les deux fonctionnalités qui la ploient – l’identification de type à l’exécution et les exceptions – sont précisément les deux que la plupart des compilateurs vous laissent désactiver.⁶ Ce principe explique pourquoi une abstraction C++ comme un pointeur intelligent ou un itérateur peut compiler vers le même code machine que la version brute, optimisée à la main.

Qu’est-ce que RAII, et pourquoi Stroustrup l’a-t-il inventé ?

RAII – Resource Acquisition Is Initialization – est le motif C++, nommé par Stroustrup, qui lie la durée de vie d’une ressource à la durée de vie d’un objet sur la pile : vous acquérez la ressource dans le constructeur de l’objet et vous la libérez dans son destructeur.⁷ Comme C++ garantit que le destructeur d’un objet sur la pile s’exécute à l’instant où il quitte sa portée – que la fonction se termine normalement ou qu’une exception déroule la pile – des ressources comme la mémoire, les fichiers, les verrous et les sockets sont libérées de façon déterministe, à un instant connu, sans ramasse-miettes et sans rien à libérer manuellement. Cela vous offre un nettoyage automatique et sûr face aux exceptions à surcoût nul, et Rust l’a ensuite repris presque intégralement sous la forme de l’ownership et de Drop.⁷

Pourquoi Stroustrup a-t-il créé C++, et d’où vient-il ?

Pendant la rédaction de son doctorat à Cambridge sur les systèmes distribués (achevé en 1979), Stroustrup a construit un simulateur en Simula et en a adoré les abstractions de classe, mais l’a trouvé trop lent à grande échelle ; il l’a réécrit en BCPL, rapide mais trop bas niveau pour y bâtir quoi que ce soit d’ampleur.² Aucun de ces compromis n’était acceptable, alors aux Bell Labs – face à un problème d’analyse du noyau UNIX à travers un réseau – il entreprit d’ajouter à C la puissance d’organisation de Simula sans perdre la vitesse de C. Il l’appela « C with Classes » (1979) ; son collègue Rick Mascitti suggéra le nom C++ en 1983.⁴⁵ En 2018, la National Academy of Engineering lui décerna le Charles Stark Draper Prize – la plus haute distinction américaine en ingénierie, une récompense de 500 000 dollars souvent appelée le prix Nobel de l’ingénierie – pour son travail de conception et d’implémentation du langage de programmation C++.⁹

Sources