Safety ist eines der meistgebrauchten und zugleich am wenigsten präzisierten Schlagworte der aktuellen Debatte über Programmiersprachen. Kaum ein Begriff wird häufiger instrumentalisiert und seltener in seiner ganzen Tragweite betrachtet. In der öffentlichen Diskussion wird Safety oft auf Memory Safety reduziert, gelegentlich ergänzt um das Versprechen, ganze Fehlerklassen per Sprachdesign zu verbieten. Doch diese Vereinfachung wird der Realität komplexer Softwaresysteme nicht gerecht und sie verkennt, dass Sicherheit kein binärer Zustand ist, sondern ein vielschichtiges Kontinuum.
Betrachtet man reale Systeme, dann beginnt Safety nicht bei der Unterbindung von Use after free, sondern bei der Fähigkeit eines Systems, dauerhaft stabil zu bleiben, unter Last vorhersehbar zu reagieren und alle fachlichen Anforderungen korrekt umzusetzen. Ein sicheres System ist eines, das in angemessener Zeit antwortet, dass bei Fehlern reagiert, anstatt zu kollabieren, dass seine Ressourcen vollständig kontrolliert und das über Jahre und Jahrzehnte weiterentwickelt werden kann, ohne getestete und bewährte Codebasen zu entwerten. Safety umfasst damit Laufzeitgarantien, fachliche Richtigkeit, Ressourcensicherheit, Datensicherheit, Robustheit und Evolution. Wer Safety auf Speicher reduziert, ignoriert den größten Teil der tatsächlichen Risiken.
C++ steht in diesem Spannungsfeld seit jeher unter besonderer Beobachtung. Die Sprache gibt Entwickelnden große Freiheit und damit auch große Verantwortung. Diese Freiheit war nie ein Versehen, sondern eine bewusste architektonische Entscheidung. C++ richtet sich an Expert*innen und an Architekt*innen, die reale und universelle Probleme lösen müssen, Probleme, die sich nicht auf ein einzelnes Sicherheitsmodell reduzieren lassen. Gerade diese Offenheit macht C++ für sicherheitskritische Domänen attraktiv und zugleich angreifbar in einer Debatte, die einfache Antworten bevorzugt.
In diesem Kontext sind die von Bjarne Stroustrup vorgeschlagenen Profiles von besonderer Bedeutung, auch wenn sie es bislang nicht in C++26 geschafft haben. Profiles sind kein Versuch, C++ nachträglich zu zähmen oder zu kastrieren, sondern ein Angebot zur Präzisierung von Verantwortung. Sie erlauben es, Sicherheitsannahmen explizit zu machen und maschinell überprüfbar zu definieren, ohne die Sprache in inkompatible Dialekte zu zerlegen. Ein Profil beschreibt nicht, was C++ ist, sondern unter welchen Annahmen C++ in einem bestimmten Kontext genutzt wird.
Der entscheidende Punkt ist dabei, dass Profiles mehrwertig sind. Sie bilden unterschiedliche Sicherheitsniveaus, Einsatzszenarien und Qualifikationsstufen ab. Ein System kann in unterschiedlichen Teilen unterschiedliche Profile verwenden, bewusst eskalieren oder deeskalieren und diese Entscheidungen transparent dokumentieren. Safety wird damit graduell, kontextsensitiv und nachvollziehbar. Das entspricht der Realität großer Systeme deutlich besser als jede binäre Klassifikation.
Demgegenüber steht das Borrow Konzept von Rust, das häufig als Gegenmodell präsentiert wird. Rust bietet starke formale Garantien, aber sein Sicherheitsmodell ist monokausal. Es setzt Safety weitgehend mit Memory Safety gleich und erzwingt dafür eine bestimmte Sicht auf Ownership und Lebensdauer. Dieses Modell ist in sich konsistent, aber nicht architekturneutral. Es eignet sich hervorragend für bestimmte Problemklassen und erweist sich in anderen als strukturelles Hindernis. Vor allem aber bleibt Safety dort binär. Code ist entweder safe oder unsafe, wobei unsafe nicht graduell, sondern kategorisch verstanden wird und sich primär auf Speicher bezieht.
Diese Zweiteilung verkennt, dass Sicherheit in realen Systemen nicht dort endet, wo der Borrow Checker zufrieden ist. Fachliche Fehler, Deadlocks, Latenzprobleme, Protokollverletzungen oder evolutionäre Brüche bleiben davon unberührt. Unsafe markiert lediglich das Ende einer sehr spezifischen Garantie, nicht das Ende des Risikos. Profiles hingegen würden unterschiedliche Garantieräume explizit machen und damit auch für Werkzeuge, statische Analyse und Zertifizierungsprozesse nutzbar.
Ein oft übersehener Aspekt von Safety ist ihre zeitliche Dimension. Software ist kein statisches Artefakt, sondern ein langlebiges System. Sicherheit bedeutet auch, dass Code über Jahrzehnte wartbar bleibt, analysierbar ist und weiterentwickelt werden kann, ohne dass implizite Annahmen zerbrechen. C++ hat hier eine seltene Stärke. Die Sprache wächst evolutionär, entwertet alte Abstraktionen nicht und erlaubt es, neue Sicherheitsmechanismen schrittweise einzuführen. Viele Safety Argumente anderer Sprachen setzen implizit einen Greenfield Kontext voraus und ignorieren die Realität gewachsener Systeme.
Hinzu kommt eine ökonomische Dimension. Unsichere Systeme entstehen selten aus Unwissen, sondern aus Zeitdruck und Kostenzwängen. Eine Sprache, die Safety nur als Alles oder Nichts anbietet, erzeugt starken Druck, Sicherheitsmechanismen zu umgehen. Graduelle Safety, wie sie Profiles ermöglichen würden, erlaubt es, Sicherheit inkrementell zu erhöhen und wirtschaftlich tragfähig umzusetzen. Das ist kein technischer Nebenaspekt, sondern eine Voraussetzung für reale Sicherheit.
Die Diskussion um Java zeigt, wohin die Verwechslung von Verbot und Sicherheit führen kann. Java hat viele Freiheiten abgeschafft und damit den Sicherheitsraum verengt, aber nicht automatisch sichere Systeme erzeugt. Risiken außerhalb dieses Raumes wurden unsichtbar, nicht eliminiert. In der aktuellen politischen Diskussion um sichere Programmiersprachen wiederholt sich dieses Muster. Sicherheit wird als Reduktion von Freiheitsgraden verstanden, nicht als Erhöhung von Kompetenz und Bewusstsein.
C++ muss hier selbstbewusster werden. Die Sprache ist kein Relikt einer unsicheren Vergangenheit, sondern ein Werkzeug für verantwortungsbewusste Experten. Safety entsteht nicht durch Entmündigung, sondern durch explizite Modelle, durch Qualifikation, durch Werkzeuge und durch ein Bewusstsein für Probleme, das über Speicher hinausgeht. Profiles wären ein Weg, diese Haltung zu präzisieren und sichtbar zu machen, nicht sie aufzugeben.
Letztlich ist bessere Qualifikation die einzige nachhaltige Lösung. Profiles können diesen Lernweg absichern, indem sie Sicherheitsannahmen explizit machen und graduelle Verantwortung erlauben. Sie sind kein Ersatz für Expertise, sondern ein Mittel, sie wirksam werden zu lassen. In einer Zeit, in der einfache Narrative dominieren, ist das vielleicht die unbequemere, aber die realistischere Antwort auf die Frage nach Safety in C++.
Über den Autor
Volker Hillmann stammt aus Norddeutschland und ist Mathematiker sowie Softwarearchitekt mit einem interdisziplinären Hintergrund zwischen formaler Wissenschaft und angewandter Informatik. Sein Mathematikstudium verbindet klassische Strenge mit logischem und kybernetischem Denken, ergänzt durch eine langjährige Beschäftigung mit Chaosmathematik, Systemtheorie und Künstlicher Intelligenz. Der Informatikschwerpunkt seiner Arbeit liegt auf Datenbanken, Datensicherheit und Softwarearchitektur – mit einer konsequent modernen Ausrichtung auf C++.
Seit 1988 programmiert er in Turbo C, seit 1991 in Turbo C++, und kennt die Entwicklung der Sprache wie auch der Werkzeuge aus erster Hand. Er hat zahlreiche Vorträge über C++ und Softwarearchitektur gehalten und ist seit 2001 selbständig tätig. Seit Mitte der 2000er-Jahre ist er außerdem Embarcadero MVP und engagiert sich besonders für die Weiterentwicklung und praktische Anwendung des C++Builder.
Seine Leidenschaft gilt modernem C++:
In seinen kostenlosen Livestreams beschäftigt er sich ausschließlich mit aktuellem C++, unabhängig vom Compiler – sei es MSVC, GCC oder dank der neuen Version auch wieder der C++Builder. Dabei geht es nie um ein bestimmtes Werkzeug, sondern immer um die Sprache selbst: C++ als Ausdruck von Architektur, Präzision und Denken.
Er versteht C++ nicht nur als Werkzeug, sondern auch als Sprache des Denkens. C++ ist eine Plattform für strukturiertes, effizientes und sicheres Entwerfen. In seinen aktuellen Streams und Artikeln testet und analysiert er den C++Builder 13, um zu zeigen, wo modernes C++ in der Praxis steht, welche Möglichkeiten bereits bestehen und welche Grenzen es noch zu überschreiten gilt.
Seine Themen reichen von RAII und Move-Semantik über Coroutinen, Ranges und Concepts bis hin zu Compile-Time-Metaprogrammierung und Typsicherheit. Als Mathematiker denkt er in Systemen und Relationen, in ranges, tuples und Abbildungen, und überträgt diese Sichtweise konsequent auf Softwarearchitektur. Er steht für ein Verständnis von C++, das Verantwortung, Präzision und Evolution miteinander verbindet, und zeigt, dass diese Sprache weder veraltet noch unsicher ist, sondern die präziseste und ehrlichste Form des Softwareentwurfs.
Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Free Delphi Community Edition Free C++Builder Community Edition
