08.10.2026 · Signal Titans Editorial
Bjarne Stroustrup wollte sich nicht zwischen Abstraktion und Geschwindigkeit entscheiden
Als Bjarne Stroustrup 1979 zu Bell Labs kam, brachte er ein Problem mit, das Softwareentwicklern bis heute vertraut ist: Das Programmiermodell, das ein System verständlicher macht, ist nicht automatisch dasjenige, das schnell genug läuft. In seiner Arbeit an verteilten Systemen hatte er Simula kennengelernt und dessen Klassen und Strukturierungsmöglichkeiten geschätzt. Gleichzeitig wollte er die Effizienz, Portabilität und hardwarenahe Kontrolle von C behalten. Statt sich für eine Seite zu entscheiden, begann er ein Experiment, das zunächst „C with Classes“ hieß.
Die Einschränkung kam vor der Sprache
Stroustrup startete nicht mit dem Ziel, C zu ersetzen. Seine konkrete Aufgabe betraf die Verteilung von Betriebssystemfunktionen über ein Netzwerk. Die praktische Frage lautete: Wie lässt sich ein komplexes System mit stärkeren Abstraktionen beschreiben, ohne einen Leistungsaufschlag zu akzeptieren, der es für Systemsoftware untauglich macht? C verfügte bereits über Compiler, Entwickler, Betriebssysteme und eine Kultur der Effizienz. Simula bot bessere Werkzeuge zur Strukturierung. Die neue Sprache musste mit beiden Welten funktionieren.
Deshalb greift die Beschreibung „C plus objektorientierte Syntax“ zu kurz. In Stroustrups eigenen Rückblicken wird deutlich, dass er Programme zugleich effizient und elegant schreiben wollte. Kompatibilität, Abstraktionen ohne unnötige Laufzeitkosten und eine realistische Implementierung waren von Anfang an zentrale Entwurfsdrücke.
„C with Classes“ war eine brauchbare Brücke
Die erste Implementierung nutzte einen Präprozessor, der die neuen Klassenkonstrukte in C übersetzte. Später schrieb Stroustrup Cfront, ein vollständigeres Compiler-Frontend, das Syntax und Semantik selbst prüfte und anschließend C-Code ausgab. Das war nicht nur ein technischer Trick. Dadurch konnte das Experiment in der vorhandenen Bell-Labs-Umgebung eingesetzt und an echten Projekten erprobt werden, ohne zuerst eine komplett neue Compilerwelt bauen zu müssen.
Anfang der 1980er Jahre war die Nutzergruppe so groß geworden, dass „C with Classes“ als Ein-Mann-Forschungsprojekt kaum noch zu betreuen war. Stroustrup beschrieb später die Wahl: das Experiment aufgeben oder daraus eine flexiblere und ausdrucksstärkere Sprache entwickeln. Er entschied sich für die zweite Möglichkeit. In dieser Phase entstand der Name C++, und 1985 erschienen sowohl die erste kommerzielle Version als auch die erste Ausgabe von The C++ Programming Language.
Abstraktion, ohne die Maschine zu verlassen
C++ erhielt stärkere Typprüfung, Klassen, Konstruktoren, Operatorüberladung, virtuelle Funktionen und später Templates sowie eine umfangreiche Standardbibliothek. Dauerhafter als einzelne Features war jedoch das zugrunde liegende Versprechen: Entwickler sollten höherwertige Abstraktionen bauen können, die sich effizient auf die Hardware abbilden lassen. Bequemlichkeit sollte nicht automatisch eine versteckte Laufzeitsteuer bedeuten. Diese Haltung machte C++ attraktiv für Systemsoftware, Grafik, Spiele, Finanzanwendungen, wissenschaftliches Rechnen und andere Bereiche, in denen Architektur und Ausführungskosten gleichermaßen zählen.
Dieses Versprechen hat seinen Preis. C++ wurde komplexer, weil es alte Programme bewahren, neue Programmierstile unterstützen und weiterhin hardwarenah bleiben wollte. Kritik an Umfang und Schwierigkeit der Sprache ist daher berechtigt. Gleichzeitig hängt diese Komplexität mit derselben historischen Entscheidung zusammen, die C++ so langlebig machte: Die Sprache sollte in eine bestehende Welt passen, nicht verlangen, dass diese Welt von vorn beginnt.
Standardisierung veränderte die Verantwortung
Mit der Verbreitung außerhalb von Bell Labs konnte keine einzelne Implementierung die Sprache dauerhaft definieren. Ende der 1980er Jahre begann die Standardisierungsarbeit; 1998 wurde der erste ISO-C++-Standard ratifiziert. Von da an entwickelte sich C++ durch ein internationales Komitee, konkurrierende Compiler, Bibliotheksentwickler und eine riesige Anwendergemeinschaft. Stroustrup blieb einflussreich, doch die Sprache wurde größer als jede persönliche Roadmap.
Das erklärt, warum heutige Änderungen oft wie Verhandlungen wirken. Neue Funktionen müssen mit jahrzehntealtem Code und Anwendungen vom eingebetteten Gerät bis zum großen Serversystem zusammenleben. Gegenüber einer neuen Sprache auf dem weißen Blatt wirkt das konservativ. Historisch gesehen ist diese Kontinuität jedoch Teil der technischen Aufgabe.
Die bleibende Lehre: nicht zu früh entscheiden
2018 erhielt Stroustrup den Charles Stark Draper Prize der National Academy of Engineering für die Konzeption und Entwicklung von C++. Der Preis würdigt die Wirkung, doch für Entwickler steckt die nützlichere Lektion in der ursprünglichen Einschränkung. Er akzeptierte nicht, dass lesbare Abstraktionen und Maschineneffizienz zwangsläufig in getrennten Sprachen leben müssten.
Heute gibt es viele Antworten auf dieselbe Spannung: verwaltete Laufzeiten, Ownership-Systeme, JIT-Compiler, funktionale Abstraktionen, sicherere Low-Level-Sprachen und spezialisierte Beschleuniger. C++ ist weder die einzige noch immer die einfachste Antwort. Seine historische Bedeutung liegt darin, gezeigt zu haben, dass Sprachdesign mehrere widersprüchliche Anforderungen gleichzeitig bewahren kann. Manchmal ist die langlebige Innovation kein einzelnes Feature, sondern die Weigerung, eine Seite eines schwierigen Zielkonflikts aufzugeben, bevor die technische Arbeit wirklich versucht wurde.
SIGNAL TITANS.jpg){kind=link}