Das AtomicObject-Team beschreibt auf seinerWebsitedie Gefahren der enormen Ausdrucksvielfalt von C++ sehr treffend:
C++ ist eine außerordentlich vielseitige Sprache. Diese Vielfalt ist zugleich Segen und Fluch: ein Segen wegen ihrer Ausdrucksstärke und der Unterstützung mehrerer Programmierparadigmen; ein Fluch, weil diese Vielfalt auch Komplexität bedeutet und vieles beherrscht werden muss. C++ ist eine Sprache, an der man wächst und bei der jede Erfahrung neue Features oder ein tieferes Verständnis vermitteln kann. Da jedes C++-Feature mit anderen interagieren kann, fühlt sich das Erlernen von C++ an, als würde man nach und nach eine keineswegs dünn besetzte Wissensmatrix füllen, die aus dem Kreuzprodukt des C++-Feature-Vektors mit sich selbst entsteht. Eine ernsthafte Nutzung der Sprache sollte nicht ohne gute Referenzwerke erfolgen.
Seit 2011 hat Microsoft in zahlreichen Artikeln das Comeback von C++ ausgerufen. Microsoft-C++-Experten wie Herb Sutter hielten viele Vorträge darüber, warum C++ zurück ist, und empfahlen dabei vor allem den Einsatz von modernem C++. Gleichzeitig wurde der C++11-Standard verabschiedet, und man begann, von C++ wie von einer neuen Sprache zu sprechen.
Doch 2011 blickte C++ bereits auf eine mehr als 30-jährige Geschichte zurück. Entwickler davon zu überzeugen, dass das neue C++ viele frustrierende Anwendungsfälle vereinfacht und einen neuen, modernen Weg zur Verbesserung von C++-Code eröffnet, ist nicht einfach.
Leider reichten all die Bemühungen der aktiven C++-Community und bekannter Experten nicht aus. Die Moral der Geschichte lautet:Wenn Sie jemandem mit einer Sprache oder einem Tool die Möglichkeit geben, etwas zu tun, sollten Sie sich nicht wundern, wenn er es auch tut.
Heute brauchen wir Schutzmechanismen, die Entwicklern helfen, sauberen C++-Code zu schreiben.
1. Ein geschützter Compiler-Modus für eine Teilmenge der Sprache
Um von der großartigen Arbeit des Standardisierungskomitees und der C++-Community zu profitieren, brauchen wir Compiler, mit denen sich einige alte C++-Features ausschließen lassen.
Natürlich stellt die Nutzung bestehender C++-Bibliotheken dabei eine große Einschränkung dar. Wenn wir jedoch davon überzeugt sind, dass C++ noch sehr lange bestehen wird, müssen wir schon heute den Übergang zu modernem C++ vorbereiten.
Bestehende Compiler sind nicht dafür ausgelegt, nur eine Teilmenge des Sprachstandards zu akzeptieren. Nach unserer Arbeit mit Clang als Parser für CppDepend können wir jedoch bestätigen, dass seine Modularität, Implementierung und leistungsfähigen Diagnosefunktionen den Mitwirkenden ermöglichen könnten, eine Version zu entwickeln, die sich über die Kommandozeile einfach so konfigurieren lässt, dass bestimmte alte Features der C++-Standards beim Kompilieren ausgeschlossen werden.
2. Compiler-Diagnosen und Warnungen
Wir brauchen mehr Diagnosen und Warnungen, die auf veraltete Verwendungen hinweisen. Clang meldet bereits viele interessante Diagnosen zu veralteten Konstrukten. Vielleicht wird es künftig auch möglich sein, den Build abzubrechen, wenn bestimmte Diagnosen auftreten.
3. Tools
Einige Tools können veraltete Verwendungen erkennen und in den Build-Prozess integriert werden, sodass der Build fehlschlägt, wenn bestimmte Regeln verletzt werden.
Clang-Tidy ist ein leistungsfähiges Tool zum Erkennen zahlreicher Schwachstellen und veralteter Verwendungen.CppDepend hat es bereits in Version 2017 integriert und bietet außerdem eine Code-Abfragesprache, mit der sich Code wie eine Datenbank abfragen lässt. Dadurch können Sie Ihre Coding-Regeln einfach anpassen und veraltete Verwendungen erkennen.
Kurz gesagt: Wir brauchen bessere Lösungen, um C++-Entwickler beim Übergang zu modernem C++ zu unterstützen.