In einer Antwort vom 15. März auf eine Anfrage von InfoWorld, verwies Stroustrup auf die Stärken von C++. „Ich finde es überraschend, dass die Verfasser dieser Regierungsdokumente die Stärken des modernen C++ und die Bemühungen um starke Sicherheitsgarantien offenbar nicht wahrnehmen“, sagte Stroustrup.
Stroustrup hob einen zentralen Punkt hervor, der dem Problem zugrunde liegt:
Bei der Sicherheit gibt es zwei Probleme. Von den Milliarden Zeilen C++ halten sich nur wenige vollständig an moderne Richtlinien, und die Vorstellungen darüber, welche Sicherheitsaspekte wichtig sind, unterscheiden sich.
Das verdeutlicht ein wesentliches Problem von C++. Wenn eine Programmiersprache potenziell gefährliche Aktionen zulässt, sollte es nicht überraschen, dass ein beträchtlicher Teil der Entwickler diese Möglichkeiten falsch nutzt.
Werden Entwickler mit schlechtem Code konfrontiert, führen sie mitunter verschiedene Argumente zur Rechtfertigung an – häufig sind es jedoch eher Ausreden als stichhaltige Gründe:
- Enge Fristen: „Wegen enger Fristen musste ich mich beeilen. Es blieb nicht genug Zeit, sauberen Code zu schreiben.“
- Legacy-Code: „Die bestehende Codebasis ist unübersichtlich und schlecht strukturiert. Meine Änderungen gehen im vorhandenen Chaos einfach unter.“
- Schleichende Ausweitung des Projektumfangs: „Die Anforderungen änderten sich während des gesamten Projekts ständig, wodurch sauberer Code schwer beizubehalten war.“
- Technologische Einschränkungen: „Der verwendete Technologie-Stack eignet sich nicht für sauberen Code. Wir sind durch die vorhandenen Technologien eingeschränkt.“
Ja, Entwickler tragen die Verantwortung dafür, ihren C++-Code korrekt zu schreiben. Dieser Ansatz könnte für die Zukunft von C++ jedoch riskant sein. Vor einigen Jahren haben wir den Niedergang von Nokia erlebt. Der Absturz vom weltweit führenden Mobiltelefonhersteller zu einem Unternehmen mit großen Marktproblemen hatte mehrere Ursachen und strategische Fehlentscheidungen. Eine der entscheidenden Fehlentscheidungen war, zu lange am Betriebssystem Symbian festzuhalten. Symbian war einst eine dominante Plattform, konnte beim Benutzererlebnis aber nicht mit iOS und Android mithalten.
Auch in C++ verlassen wir uns schon zu lange auf die bestehenden Mechanismen zur Speicherverwaltung. Eine grundlegende Lösung wurde bislang nicht vorgeschlagen – lediglich einige Verbesserungen, die von den Entwicklern selbst angewendet werden müssen.
C++ im Vergleich zur .NET-Strategie:
C# wurde im Jahr 2000 hauptsächlich für Windows-Systeme entwickelt. Miguel de Icaza schuf Mono, um die Nutzung unter Linux und macOS zu ermöglichen. Nachdem das klassische .NET Framework jedoch mehr als ein Jahrzehnt vorwiegend unter Windows eingesetzt worden war, wurde die Portabilität zu einem erheblichen Problem. Microsoft arbeitete deshalb mit Miguel zusammen und entwickelte .NET Core, eine Variante von .NET, die auch auf anderen Betriebssystemen funktionieren sollte.
Das war keine schrittweise, sondern eine grundlegende Lösung des Portabilitätsproblems, auch wenn ein Teil des Legacy-Codes inkompatibel war. Miguel de Icaza beschrieb .NET Core damals als eine „neu gestaltete Version von .NET die auf einer vereinfachten Version der Klassenbibliotheken basiert“, und Microsofts Immo Landwerth erklärte, .NET Core werde „die Grundlage aller zukünftigen .NET-Plattformen“.
Letztlich funktionierte diese Lösung sehr gut: .NET Core fand breite Verbreitung und das große Portabilitätsproblem wurde gelöst.
Warum nicht bei C++ einen ähnlichen Weg einschlagen, um Sicherheitsprobleme entschlossener anzugehen? Warum nicht eine sichere Teilmenge von C++ entwickeln und über den Compiler die Möglichkeit bieten, ausschließlich mit dieser Teilmenge zu arbeiten?
clang --safeFazit:
Solange C++ Entwicklern weiterhin unsichere Praktiken bei der Speicherverwaltung erlaubt, wird dieses erhebliche Sicherheitsproblem bestehen bleiben. Dadurch könnten bei neuen Projekten zunehmend andere Sprachen wie Rust oder Go bevorzugt werden. Vielleicht ist es an der Zeit, eine grundlegendere Lösung in Betracht zu ziehen, statt ausschließlich auf schrittweise Verbesserungen zu setzen. Die Erfahrung zeigt jedenfalls: Obwohl C++ seit mehr als einem Jahrzehnt moderne Funktionen zur Verbesserung der Sicherheit bietet, besteht das Problem fort, weil die Sprache weiterhin unsichere Legacy-Praktiken zulässt.