Engineering-Philosophie: Bjarne Stroustrup, Abstraktion ohne Overhead

Die wichtigsten Erkenntnisse

• Abstraktion ohne Overhead. Stroustrup schuf C++, um die falsche Wahl zwischen klarem Code und maschinennaher Geschwindigkeit zu beenden – die ausdrucksstarke Variante und die von Hand optimierte Variante sollten zum selben Maschinencode kompilieren.
• Das Zero-Overhead-Prinzip. „Was Sie nicht nutzen, dafür zahlen Sie nicht; was Sie nutzen, könnten Sie von Hand nicht besser schreiben” – das ist die Regel, die jede Funktion in C++ bestehen muss.
• RAII macht es greifbar. Die Lebensdauer einer Ressource an ein Objekt auf dem Stack zu binden, ermöglicht ein deterministisches, ausnahmesicheres Aufräumen ganz ohne Garbage Collector – ein Muster, das Rust später nahezu vollständig übernahm.
• Keinen Spielraum darunter lassen. C++ muss die höchste Sprache bleiben, zwischen der und dem Silizium nichts steht außer dem Assembler – sonst würde eine maschinennähere Sprache ihren Platz einnehmen.

Das Prinzip

„Was Sie nicht nutzen, dafür zahlen Sie nicht. Und weiter: Was Sie nutzen, könnten Sie von Hand nicht besser schreiben.” – Bjarne Stroustrup, das Zero-Overhead-Prinzip¹

Dieser Satz ist der wichtigste in der Systemprogrammierung, und er trägt zwei Versprechen in sich. Die erste Hälfte besagt, dass eine Abstraktion dort kostenlos sein muss, wo sie nicht genutzt wird: Greifen Sie auf eine Funktion zu, kostet sie Sie etwas; ignorieren Sie sie, kostet sie Sie nichts – kein Byte Speicher, keinen Takt Laufzeit. Die zweite Hälfte ist das schwerere Versprechen: Wenn Sie die Abstraktion tatsächlich nutzen, muss der Compiler Maschinencode erzeugen, der mindestens so gut ist wie das, was ein kompetenter Programmierer für genau diese Aufgabe von Hand geschrieben hätte. Ein Vektor, der im Release-Modus keine Grenzen prüft. Ein Smart Pointer, der zu einem nackten Zeiger kompiliert. Ein Iterator, der in einer rohen Schleife verschwindet. Die Klarheit ist umsonst zu haben.

Die meisten Sprachen erzwingen einen Kompromiss. Sie bekommen entweder die hochsprachliche, ausdrucksstarke Variante, die langsam ist, oder Sie steigen auf die maschinennahe, schnelle Variante hinab, die unleserlich ist – und das ganze Handwerk wird zur Frage, welchen Schmerz Sie an welchem Tag in Kauf nehmen. Stroustrups gesamte Laufbahn ist eine Verweigerung dieses Kompromisses. Er hatte ihn am eigenen Leib gespürt: Als Doktorand liebte er die Abstraktionen von Simula, fand sie aber für echte Arbeit zu langsam, und er liebte die Geschwindigkeit von BCPL, fand sie aber zu maschinennah, um damit etwas Großes zu bauen.² C++ existiert, weil er entschied, dass man nicht wählen können sollte. Effizienz und Abstraktion waren keine gegenläufigen Regler, die man austarieren musste; sie sollten zusammen ankommen, in derselben Codezeile.

Diese Überzeugung ist dieselbe, die dem Argument zugrunde liegt, dass Leistung keine Funktion ist, die man hinzufügt, sondern eine Eigenschaft, die man nicht verlieren darf. Eine Zero-Overhead-Abstraktion ist nicht etwas Schnelles, das auf einer langsamen Sprache aufsetzt. Sie ist etwas Klares, das der Compiler exakt auf das herunterschleift, was Sie von Hand geschrieben hätten – sodass Sie für die Klarheit niemals bezahlen. „Ich mag meinen Code elegant und effizient”, hat er gesagt – und das Wort, auf das es ankommt, ist das und. Er hasst es, zwischen beidem wählen zu müssen.³

Hintergrund

Bjarne Stroustrup wurde am 30. Dezember 1950 in Aarhus, Dänemark, geboren.⁴ Er studierte Mathematik und Informatik an der Universität Aarhus und ging dann für eine Promotion an das Computing Laboratory der University of Cambridge in England, die er 1979 abschloss. Seine Dissertation – „Communication and control in distributed computer systems” – befasste sich damit, wie sich die Arbeit eines Betriebssystems über ein Netzwerk von Computern verteilen lässt.⁴

Um dieses Problem zu untersuchen, brauchte er einen Simulator, und die erste Version schrieb er in Simula, der norwegischen Sprache (entworfen von Ole-Johan Dahl und Kristen Nygaard), die der Welt Klassen und Objekte vorgestellt hatte. Stroustrup liebte sie. Die Klassenabstraktionen von Simula erlaubten es ihm, ein großes, verzweigtes Programm so zu organisieren, wie das Problem organisiert war, nicht so, wie die Maschine es war – und das Programm zu schreiben und zu verändern war ein Vergnügen. Dann versuchte er, es im großen Maßstab auszuführen, und die Abstraktionen brachen unter ihrem eigenen Preis zusammen. Die Implementierung war zu langsam, um praktikabel zu sein. Er schrieb den Simulator in BCPL neu, einer abgespeckten Systemsprache, und bekam die Geschwindigkeit zurück – doch BCPL war so maschinennah, dass es ein Elend war, darin etwas Großes zu bauen.² Dieser Schleudertrauma-Moment war die prägende Wunde. Er hatte die ausdrucksstarke Sprache genutzt und mit Leistung dafür bezahlt, dann die schnelle Sprache genutzt und mit allem anderen dafür bezahlt. Keines von beidem war hinnehmbar. Beide Hälften hätten zugleich möglich sein müssen.

Diesen Groll trug er 1979 zu Bell Labs in New Jersey, wo er erneut vor einem Problem verteilter Systeme stand: dem Analysieren des Datenverkehrs des UNIX-Kernels über ein Netzwerk hinweg. In Erinnerung an Cambridge machte er sich daran, die Organisationskraft von Simula zu C hinzuzufügen – einer Sprache, die bereits schnell und hardwarenah war, der Systemsprache von UNIX – ohne ein Quäntchen von Cs Geschwindigkeit aufzugeben.⁴⁵ Das Ergebnis nannte er „C with Classes”. 1983 schlug sein Kollege Rick Mascitti den Namen C++ vor, den Inkrement-Operator, angewandt auf C selbst: das nächste C, eines besser, dieselbe Maschine darunter.⁵

Das Werk

Von C with Classes zu C++: Ein besseres C, das nichts kostet

Der ursprüngliche Schritt (1979–1983) war bewusst bescheiden und genau richtig. Man nehme C – bereits schnell, bereits direkt auf die Hardware abgebildet, bereits die Systemsprache, der die Leute vertrauten – und füge hinzu, was Simula ihn zu wollen gelehrt hatte: Klassen, bessere Typprüfung, Datenabstraktion.⁵ Entscheidend war, dass er sie als eine Schicht hinzufügte, für die C-Programmierer nicht bezahlen mussten. Ein C-Programm war immer noch ein gültiges C++-Programm. Ein struct, das keine der neuen Funktionen nutzte, kompilierte zu denselben Bytes wie eh und je. Die neue Mächtigkeit war optional, und ihre Nutzung kostete nur so viel, wie das gleichwertige, von Hand geschriebene C gekostet hätte. Das ist das Zero-Overhead-Prinzip im Keim, vorhanden, bevor er einen Namen dafür hatte: die Leute nicht zu besteuern, die die Funktion nicht nutzen, und der Funktion nicht zu erlauben, schlechteren Code zu erzeugen, als sie selbst geschrieben hätten.

Er dokumentierte und stabilisierte die Sprache in The C++ Programming Language (1985), dem Buch, das sie allgemein verfügbar machte, und verbrachte dann Jahrzehnte damit, ihren Kern durch den Entwurf jeder späteren Funktion zu verteidigen.⁴

Das Zero-Overhead-Prinzip

Das Zero-Overhead-Prinzip ist die tragende Idee, die Regel, an der jede Funktion in C++ gemessen wird. Stroustrup formuliert es in zwei Teilen: „Was Sie nicht nutzen, dafür zahlen Sie nicht (an Zeit oder Platz), und weiter: Was Sie nutzen, könnten Sie von Hand nicht besser schreiben.”¹ Der erste Teil ist eine Steuerpolitik – keine Funktion darf Code belasten, der sie nicht nutzt. Der zweite ist eine Qualitätsschwelle – eine Funktion, die Sie tatsächlich nutzen, muss zu Code kompilieren, der nicht schlechter ist als das, was ein sorgfältiger Programmierer für genau diese Aufgabe von Hand erzeugt hätte. Templates, constexpr, Move-Semantik sowie die Container und Algorithmen der Standardbibliothek sind allesamt darauf ausgelegt, es einzuhalten; die zwei berühmten Ausnahmen, Laufzeit-Typinformation und Exceptions, sind genau die beiden Funktionen, für die Compiler Schalter zum Abschalten anbieten – weil sie die Regel beugen.⁶

Der Gewinn ist die Sache, die unmöglich klingt, bis Sie den Assembler sehen: Die ausdrucksstarke und die von Hand optimierte Variante erzeugen denselben Maschinencode.

Diese Identität – ausdrucksstark und von Hand optimiert, die in einer einzigen Ausgabe zusammenfallen – ist der Grund, warum das Prinzip ebenso moralisch wie technisch ist. Es nimmt dem Ingenieur seine Standardausrede. Wäre Klarheit wirklich teuer, könnten Sie das Schreiben der hässlichen, schnellen Variante rechtfertigen, „weil es schnell sein muss”. Stroustrups Wette ist, dass die Ausrede meist eine Lüge ist – dass eine gut entworfene Abstraktion Ihnen die lesbare Variante und die schnelle ermöglicht, weil sie ein und dieselbe Variante sind. Der Preis wurde einmal entrichtet, vom Sprachentwerfer, damit er nie wieder vom Programmierer entrichtet werden muss.

RAII und deterministische Ressourcen

Das Prinzip brauchte einen Mechanismus für den unübersichtlichsten Teil der Systemprogrammierung: Ressourcen, die belegt und dann zuverlässig wieder freigegeben werden müssen – Speicher, Dateien, Locks, Sockets. Garbage Collection beantwortet dies, indem sie auf Determinismus verzichtet: Das Aufräumen geschieht irgendwann, nach dem Zeitplan des Collectors, was für ein Lock oder ein Datei-Handle untragbar ist. Stroustrups Antwort, die er RAII – Resource Acquisition Is Initialization nannte, bindet die Lebensdauer einer Ressource an die Lebensdauer eines Objekts auf dem Stack.⁷ Sie belegen die Ressource in einem Konstruktor; Sie geben sie im Destruktor frei; und weil C++ garantiert, dass der Destruktor eines Stack-Objekts in dem Augenblick läuft, in dem es seinen Gültigkeitsbereich verlässt – normal oder über eine Exception, in umgekehrter Reihenfolge der Konstruktion –, wird die Ressource genau dann freigegeben, wann sie es sollte, deterministisch, ohne Collector und ohne ein manuelles free, das man vergessen könnte.⁷

RAII ist Zero-Overhead, greifbar gemacht. Der Destruktoraufruf ist Code, den Sie ohnehin von Hand hätten schreiben müssen; die Sprache garantiert nur, dass Sie ihn nicht vergessen können. Sie erhalten automatisches, ausnahmesicheres, deterministisches Aufräumen und zahlen nichts, was Sie nicht auch beim Aufräumen von Hand gezahlt hätten. Es ist das C++-Muster, das spätere Sprachen, allen voran Rust, nahezu vollständig übernehmen sollten.

Standardisierung und „keinen Spielraum für eine maschinennähere Sprache lassen”

Stroustrup behielt C++ nicht als persönliches Projekt. Er brachte es vor das Standardisierungskomitee – ANSI ab 1989, ISO ab 1991 – und wirkte jahrzehntelang darin mit, leitete die Evolution Working Group, damit C++ ein stabiler, herstellerneutraler Standard würde und nicht der Dialekt eines einzelnen Unternehmens.⁴ Und er gab dem Komitee eine grundgesetzartige Regel mit, abgeleitet aus seinen Entwurfsprinzipien in The Design and Evolution of C++: „Lass keinen Spielraum für eine maschinennähere Sprache unterhalb von C++ (außer dem Assembler).”⁸ Die Begründung ist präzise – könnte man in irgendeiner Sprache zwischen C++ und dem nackten Metall effizienteren Code schreiben, dann würde diese Sprache zur Systemsprache der Wahl, und C++ verlöre seine Daseinsberechtigung.⁸ Um lebensfähig zu bleiben, muss C++ Cs direkten Hardwarezugriff, seine Kontrolle über das Datenlayout und seine primitiven Typen behalten, die eins zu eins auf die Maschine abbilden.⁸ Zwischen der Abstraktion und dem Silizium sollte nichts stehen außer dem Assembler. Das Zero-Overhead-Prinzip, formuliert als Wettbewerbsgrenze: die höchste Sprache zu sein, die dennoch nichts auf dem Tisch liegen lässt.

Die Methode

Die Methode ist eine einzige Wette – Klarheit und Geschwindigkeit sind dasselbe, wenn man die Abstraktion richtig entwirft –, durchgesetzt als ein Satz harter Regeln.

Jede Funktion am Zero-Overhead messen. Keine Funktion darf Code besteuern, der sie nicht nutzt, und keine Funktion darf Code erzeugen, der schlechter ist als das von Hand geschriebene Äquivalent. Das ist die Schwelle, die jede Erweiterung von C++ seit vierzig Jahren bestehen muss.¹⁶

Dem Programmierer vertrauen und mehrere Paradigmen unterstützen. C++ unterstützt prozedurale, objektorientierte, generische und funktionale Stile, weil Stroustrup sich weigerte, für Sie zu entscheiden, wie Sie Ihr Problem organisieren. Die Sprache gibt Ihnen die Werkzeuge und setzt voraus, dass Sie Ihre Domäne besser kennen als der Sprachentwerfer.⁶

Direkt auf die Hardware abbilden. Cs Eins-zu-eins-Entsprechung zwischen primitiven Typen, Datenlayout und der Maschine beibehalten. Die Abstraktion sitzt auf dem Metall, nicht über einer Laufzeitumgebung, die es verbirgt.⁸

Aufräumen deterministisch machen, nicht irgendwann. RAII bindet die Lebensdauer der Ressource an die des Objekts, sodass die Freigabe zu einem bekannten Augenblick erfolgt, ausnahmesicher, ohne Garbage Collector und ohne dass man an ein free denken müsste.⁷

Sie offen stabilisieren. Die Sprache einem internationalen Standardisierungskomitee übergeben, statt sie zu besitzen, damit C++ ein dauerhafter öffentlicher Standard ist und kein einzelner Hersteller sie abspalten kann.⁴

Einflusskette

Wer ihn prägte

Ole-Johan Dahl und Kristen Nygaard, über Simula. Simula lehrte Stroustrup, wofür Abstraktion gut ist – ein Programm so zu strukturieren, wie das Problem strukturiert ist –, und ihre Langsamkeit lehrte ihn die andere Hälfte der Lektion: dass Abstraktion wertlos ist, wenn man es sich nicht leisten kann, sie zu nutzen. C++ ist der Versuch, Simulas Gabe zu behalten und keinen ihrer Kosten zu zahlen. (Direkter, prägender Einfluss)

BCPL und die Kultur der Systemprogrammierung rund um C und UNIX. BCPL bescherte ihm den gegenteiligen Schmerz – rohe Geschwindigkeit ohne jede Möglichkeit, etwas Großes zu organisieren –, und C, die Sprache von UNIX bei den Bell Labs, gab ihm das schnelle, auf die Hardware abgebildete Fundament, um C++ darauf aufzubauen statt anstelle davon.²⁵ (Direkter Einfluss)

Bell Labs. Dieselbe Institution, die C und UNIX hervorbrachte, stellte Stroustrup das Problem verteilter Systeme, das „C with Classes” auslöste, und die Forschungskultur, die es ihm erlaubte, Jahre darauf zu verwenden, die Sprache richtig hinzubekommen. (Prägender Einfluss)

Wen er prägte

Die Infrastruktur der Welt läuft auf seiner Sprache. Betriebssysteme, Browser, Datenbanken, Spiel-Engines, Compiler, Hochfrequenzhandelssysteme, die Flugsoftware der Mars-Rover – der leistungskritische Kern des modernen Computings ist überproportional C++. Die Arbeit weniger Ingenieure ist derart tragend.

Die Bewegung der Zero-Cost-Abstraktionen. Stroustrups Prinzip, umbenannt in „Zero-Cost-Abstraktionen”, wurde zu einem expliziten Gründungsziel von Rust, das RAII (als Ownership und Drop), deterministische Destruktion und die Regel übernahm, dass hochsprachliche Konstrukte zu optimalem Maschinencode kompilieren müssen. Sprachen wie D und Carbon entstammen derselben Linie. Die Idee, dass man für Klarheit nicht bezahlen sollte, ist heute Mainstream, und sie ist seine.⁶

Der rote Faden

John Carmack will, dass die innere Schleife so wenig Arbeit verrichtet, wie die Physik es zulässt – „die Lichtgeschwindigkeit ist mies”, die Maschine von harten Grenzen regiert, jeder verschwendete Takt eine Entscheidung. Stroustrup reicht Carmack die Werkzeuge, um diese Schleife lesbar zu schreiben: Eine Zero-Overhead-Abstraktion ist das Versprechen, dass die klare Variante und die maschinennächste Variante derselbe Maschinencode sind, sodass Sie nie wählen müssen. Wo Barbara Liskov der Abstraktion ihre Theorie gab – Datenabstraktion, der Vertrag, den ein Typ seinen Nutzern schuldet, die Simula-zu-CLU-Linie des „man sollte gegen das programmieren, was ein Ding tut, nicht wie es funktioniert” –, gab Stroustrup dieser Theorie einen Körper, dessen Ausführung nichts kostet. Und wo Alan Kay sich Objekte als kleine Computer vorstellte, die Nachrichten austauschen, eine spät gebundene Konversation zur Laufzeit, nahm Stroustrup den entgegengesetzten Weg zu demselben Wort: Seine Objekte werden zur Übersetzungszeit aufgelöst und lösen sich in nacktem Maschinencode auf, OOP als Zero-Overhead-Organisationswerkzeug statt als lebendiger Nachrichtenbus. Dasselbe Vokabular, zwei Philosophien – die eine optimiert für Flexibilität, die andere für die Rechnung zur Laufzeit. (Serienbrücke)

Was ich daraus mitnehme

Die Lektion, die ich behalte, ist, dass „ausdrucksstark oder schnell” fast immer eine falsche Wahl ist, die schlechtes Design einem aufzwingt. Wenn ich mich dabei ertappe, die hässliche Variante zu schreiben, „weil es schnell sein muss”, ist Stroustrups Prinzip die Anklage: Das ist kein Gesetz des Computings, es ist ein Versagen, die Abstraktion zu finden, die sich von selbst auf die schnelle Sache herunterkompiliert. Die Arbeit besteht darin, die klare Variante so gut zu entwerfen, dass die Maschine aus ihr den optimalen Code erzeugt – den Preis einmal zu zahlen, im Entwurf, damit er nie wieder in jeder Zeile gezahlt wird, die sie nutzt. Das ist derselbe Maßstab wie Qualität als einzige Variable: Die Frage lautet nie „Kann ich es mir leisten, das klar zu machen?”, sondern „Warum ist meine Abstraktion so undicht, dass Klarheit überhaupt etwas kostet?”

In der Welt, in der ich jetzt baue – Agenten, Tool-Schleifen, KI-Systeme –, ist die Versuchung das Gegenteil von Zero-Overhead: einen Wrapper auf einen Wrapper stapeln, einen Modellaufruf draufsetzen, um einen langsamen Pfad zu übertünchen, jede bequeme Abstraktion stillschweigend Latenz hinzufügen lassen, die niemand misst. Der Stroustrup-Zug besteht darin, zu verlangen, dass die bequeme Schnittstelle sich auf die effiziente herunterkompiliert – dass die saubere API und der schnelle Pfad derselbe Pfad sind, wobei der Preis im Entwurf des Agentenrahmens entrichtet wird, statt jedem Aufruf in Rechnung gestellt zu werden, der hindurchfließt. Diese Überzeugung – dass Geschmack ein technisches System ist, gegen das Sie eine harte Regel halten können, und kein Bauchgefühl, das Sie behaupten – ist der rote Faden von einem Simulator aus dem Jahr 1979, der zu langsam lief, zu einem Agentenrahmen aus dem Jahr 2026, der es nicht sein sollte.

FAQ

Was ist Bjarne Stroustrups Engineering-Philosophie?

Stroustrups Überzeugung ist, dass Sie niemals zwischen ausdrucksstarkem, hochsprachlichem Code und maschinennaher Leistung wählen müssen sollten. Er baute C++ auf dem Zero-Overhead-Prinzip auf: Eine Sprachfunktion muss nichts kosten, wenn Sie sie nicht nutzen, und wenn Sie sie nutzen, muss sie zu Code kompilieren, der nicht schlechter ist als das, was Sie für diese Aufgabe von Hand geschrieben hätten.¹ Dazu kombinierte er das Vertrauen in den Programmierer (C++ ist bewusst multiparadigmatisch), die direkte Abbildung auf die Hardware, die deterministische Ressourcenverwaltung über RAII und die Stabilisierung der Sprache als offenen ISO-Standard, statt sie zu besitzen.⁴⁶⁷

Was ist das Zero-Overhead-Prinzip?

Es ist die Regel, die Stroustrup in zwei Teilen formuliert: „Was Sie nicht nutzen, dafür zahlen Sie nicht (an Zeit oder Platz), und weiter: Was Sie nutzen, könnten Sie von Hand nicht besser schreiben.”¹ Die erste Hälfte bedeutet, dass eine ungenutzte Funktion keinerlei Laufzeit- oder Speicherkosten verursacht; die zweite bedeutet, dass eine Funktion, die Sie nutzen, Code erzeugt, der mindestens so gut ist wie das, was ein kompetenter Programmierer von Hand schreiben würde. Es ist die Schwelle, die jede Funktion in C++ bestehen muss. Die beiden Funktionen, die sie beugen – Laufzeit-Typinformation und Exceptions –, sind genau jene zwei, die die meisten Compiler abschalten lassen.⁶ Das Prinzip ist der Grund, warum eine C++-Abstraktion wie ein Smart Pointer oder ein Iterator zum selben Maschinencode kompilieren kann wie die rohe, von Hand optimierte Variante.

Was ist RAII, und warum erfand Stroustrup es?

RAII – Resource Acquisition Is Initialization – ist das von Stroustrup benannte C++-Muster, das die Lebensdauer einer Ressource an die Lebensdauer eines Stack-Objekts bindet: Sie belegen die Ressource im Konstruktor des Objekts und geben sie in dessen Destruktor frei.⁷ Weil C++ garantiert, dass der Destruktor eines Stack-Objekts in dem Moment läuft, in dem es seinen Gültigkeitsbereich verlässt – ob die Funktion normal zurückkehrt oder eine Exception den Stack abwickelt –, werden Ressourcen wie Speicher, Dateien, Locks und Sockets deterministisch freigegeben, zu einem bekannten Augenblick, ohne Garbage Collector und ohne etwas, das man manuell freigeben müsste. Es beschert Ihnen automatisches, ausnahmesicheres Aufräumen ohne jeden Overhead, und Rust übernahm es später nahezu vollständig als Ownership und Drop.⁷

Warum schuf Stroustrup C++, und woher kam es?

Während er seine Cambridge-Dissertation über verteilte Systeme schrieb (abgeschlossen 1979), baute Stroustrup einen Simulator in Simula und liebte dessen Klassenabstraktionen, fand sie aber im großen Maßstab zu langsam; er schrieb ihn in BCPL neu, das schnell war, aber zu maschinennah, um darin etwas Großes zu bauen.² Keiner der beiden Kompromisse war hinnehmbar, also machte er sich bei Bell Labs – vor dem Problem, den UNIX-Kernel über ein Netzwerk hinweg zu analysieren – daran, die Organisationskraft von Simula zu C hinzuzufügen, ohne Cs Geschwindigkeit zu verlieren. Er nannte es „C with Classes” (1979); sein Kollege Rick Mascitti schlug 1983 den Namen C++ vor.⁴⁵ 2018 verlieh ihm die National Academy of Engineering den Charles Stark Draper Prize – die höchste Ingenieursauszeichnung der USA, ein mit 500.000 Dollar dotierter Preis, oft als Nobelpreis des Ingenieurwesens bezeichnet – für seine Arbeit am Entwurf und der Implementierung der Programmiersprache C++.⁹

Quellen