Wartbarer Code durch den Einsatz von modernen C++ Features<\/p>\n
Autor: Dominik Berner, bbv Software Services<\/p>\n
Die neuen Standards haben die Programmiersprache C++ merklich modernisiert und teilweise ganz neue Programmierparadigmen in die Welt von C++ eingebracht.<\/strong><\/p>\n Die „gro\u00dfen“ \u00c4nderungen, wie Variadic Templates, auto, Move-Semantik, Lambda-Ausdr\u00fccke und weitere, haben f\u00fcr viel Diskussionsstoff gesorgt und sind dementsprechend weit herum bekannt. Nebst den Sprachfeatures hat auch die Standard-Bibliothek eine merkliche Erweiterung erfahren, und viele Konzepte aus Bibliotheken wie boost wurden so standardisiert. Nebst diesen sehr sp\u00fcrbaren (und teilweise auch umstrittenen) Features gibt es eine ganze Menge an kleinen, aber feinen Spracherweiterungen, die oft weniger bekannt sind oder \u00fcbersehen werden.<\/p>\n Gerade weil diese Features oft sehr klein und teilweise fast unsichtbar sind, haben sie gro\u00dfes Potential, um im Programmiereralltag das Leben einfacher zu machen und Code ohne schwerwiegende Eingriffe sanft zu modernisieren. Es ist oft so, dass man bei der Arbeit mit bestehendem Code nicht die M\u00f6glichkeit hat, gro\u00dfe strukturelle oder von au\u00dfen sichtbare \u00c4nderungen vorzunehmen, aber genau hier k\u00f6nnen die „kleinen Features“ helfen, Code aktuell und wartbar zu halten.<\/p>\n Wartbarkeit, Lesbarkeit und Code-Qualit\u00e4t sind Themen die aus der heutigen Software-Entwicklung nicht mehr wegzudenken sind. Der Vorteil von Software gegen\u00fcber Hardware ist, das sie sich relativ leicht anpassen und \u00fcberarbeiten l\u00e4sst und insbesondere dort, wo agil gearbeitet wird, geschieht das oft sehr bewusst und immer wieder. Durch diese Volatilit\u00e4t werden gewinnen diese Qualit\u00e4tsmerkmale noch mehr an Gewicht, denn schlechter Code macht den Vorteil der einfachen Bearbeitung mehr als zunichte. Dinge wie Clean Code, das SOLID-Prinzip oder Paradigmen wie Low Coupling, Strong Cohesion sind wichtige Aspekte von Codequalit\u00e4t, aber Qualit\u00e4t beginnt bereits bei der Verwendung der Sprache selbst. Das Verwenden der zur Verf\u00fcgung gestellten Sprachfeatures und -funktionen hilft, die Absicht hinter dem geschriebenen Code zu verdeutlichen, und erleichtert oft auch das automatische Verifizieren dieser Absichten. Zudem kann oft dadurch die Menge von geschriebenem Code reduziert werden, was dem Prinzip von „Less code means less bugs“ in die H\u00e4nde spielt.<\/p>\n Ein einfacher Algorithmus kann sehr kompliziert zu verstehen sein, wenn die Schreibweise nicht den Erwartungen entsprechen oder der Autor sich einen besonders schlauen Hack zur Optimierung einfallen lie\u00df. So kann zum Beispiel das Tauschen von zwei Variablen x und y wie folgt geschrieben werden (s. Abbildung im\u00a0PDF<\/a>).<\/p>\n Dieser XOR-Swap ist zwar speichereffizient und hat in ganz spezifischen F\u00e4llen seine Daseinsberechtigung, aber intuitiv lesbar ist die Operation nicht. Selbst mit einem Code-Kommentar versehen zwingt dieses einfache Beispiel dem Leser unn\u00f6tige Denkarbeit auf. Dem gegen\u00fcbergestellt liest sich das folgende Beispiel viel einfacher (s. Abbildung im\u00a0PDF<\/a>).<\/p>\n Die folgenden 10 kleinen Features und Erweiterungen haupts\u00e4chlich aus den modernen C++-Standards helfen, Code kompakt und lesbar zu halten und somit die Code-Qualit\u00e4t zu verbessern.<\/p>\n Vererbung ist f\u00fcr viele Programmierer Fluch und Segen gleicherma\u00dfen. Einerseits hilft sie oft, Code-Duplizierung zu vermeiden, andererseits gibt es dabei – insbesondere in C++ – viele Stolpersteine, die beachtet werden m\u00fcssen. Gerade bei Refactorings an Basisklassen kommt es immer wieder vor, dass die abh\u00e4ngigen Klassen vergessen werden und man dies erst zur Laufzeit merkt. Das Schl\u00fcsselwort override schafft hier seit C++11 Abhilfe. Wann immer eine Funktion in einem Vererbungsbaum \u00fcberschrieben wird, sollte override verwendet werden. Damit wird eine \u00fcberschriebene Funktion automatisch virtuell, und der Compiler erh\u00e4lt die M\u00f6glichkeit zu \u00fcberpr\u00fcfen, ob auch tats\u00e4chlich eine Methode \u00fcberschrieben wird und ob die \u00fcberschriebene Methode auch tats\u00e4chlich virtuell ist. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Noch mehr Kontrolle \u00fcber den Vererbungsbaum erh\u00e4lt man, wenn man die Vererbung ab einem gewissen Punkt komplett unterbinden kann. Der Spezifikator final zeigt an, dass eine Klasse oder virtuelle Funktion nicht weiter \u00fcberschrieben werden kann. Dies verringert zwar den Schreibaufwand nicht, aber kommuniziert ganz klar eine Absicht hinter einen St\u00fcck Code, n\u00e4mlich dass keine weitere Vererbung erw\u00fcnscht ist. Hier hilft sogar der Compiler mit indem die Kompilierung fehlschl\u00e4gt, sollte man dies doch versuchen. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Code zu duplizieren ist dem Programmierer ein Graus, selbst wenn es sich hier um generierten Code handelt. using-Deklarationen erlauben es dem Programmierer, ein Symbol von einer deklarativen Region, wie Namensr\u00e4ume, Klassen und Strukturen in einen anderen zu „importieren“, ohne dass zus\u00e4tzlicher Code generiert wird. Bei Klassen ist dies vor allem n\u00fctzlich, um Konstruktoren von Basisklassen direkt zu \u00fcbernehmen, ohne dass alle Varianten neu geschrieben werden m\u00fcssen. Ein weiteres Beispiel ist um kovariante Implementierungen in abgeleiteten Klassen explizit zu gestalten. Damit wird dem Leser klar signalisiert, dass hier eine „fremde“ Implementation verwendet wird, die keine funktionale Modifikation erfahren hat. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n F\u00fcr Klassen und Strukturen funktioniert das schon l\u00e4nger; seit C++17 funktioniert das \u00fcbernehmen von Symbolen auch f\u00fcr (verschachtelte) Namensr\u00e4ume: (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Andere High-Level-Programmiersprachen kennen das „Verketten“ von Konstruktoren schon l\u00e4nger, und seit C++11 ist dies auch in endlich C++ m\u00f6glich. Die Vorteile von weniger dupliziertem Code und damit einfacherer Lesbarkeit und somit bessere Wartbarkeit liegen dabei auf der Hand. Gerade bei Konstruktoren, die intern komplizierte Initialisierungen und\/oder Checks durchf\u00fchren, hilft dies sehr und f\u00f6rdert die Umsetzung des RAII (Resource Allocation is Initialisation) Paradigmas. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Im Zusammenhang mit der Verwendung der oben genannten Konstruktorenvererbung mit using l\u00e4sst sich Code so noch weiter komprimieren. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Weniger Code hei\u00dft weniger Bugs, auch bei generiertem Code. Also erleichtern wir dem Compiler doch die Arbeit, Code zu generieren, den wir gar nicht wollen und brauchen. Das Keyword delete f\u00fcr Funktionsdeklaration – nicht zu verwechseln mit dem entsprechenden Ausdruck, um Objekte zu L\u00f6schen – ist eine weitere sehr starke Erweiterung in C++11, mit der ein Programmierer eine Absicht nicht nur signalisieren, sondern auch vom Compiler durchsetzen lassen kann. Mit der Verwendung von = delete kann explizit sichergestellt werden, das gewisse Operationen, wie zum Beispiel Kopieren eines Objektes, nicht vorgesehen und m\u00f6glich sind. Nat\u00fcrlich sollte die „Rule of Five“ auch beim L\u00f6schen von Funktionen beachtet werden. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Die garantiere Verhinderung von Kopien (engl. guaranteed copy elision) ist f\u00fcr den Programmierer meist unsichtbar, aber dahinter verbirgt sich gro\u00dfes Potential f\u00fcr kleineren und saubereren Code. Diese Tilgung verhindert, dass unn\u00f6tige Kopien von tempor\u00e4ren Objekten erstellt werden, wenn sie unmittelbar nach dem Erstellen einem neuen Symbol zugewiesen werden. Einige Compiler wie gcc unterst\u00fctzen dies zwar schon l\u00e4nger, aber mit C++17 wurde das Auslassen von Kopien als garantiertes Verhalten in den Standard aufgenommen. Nebst dem Effekt, dass so weniger Code generiert wird, l\u00e4sst sie den Programmierer seine Absicht, dass ein Objekt nicht kopiert oder verschoben werden darf, mit noch gr\u00f6\u00dferer Konsequenz umsetzen. Unter Verwendung des oben genannten = delete l\u00e4sst sich dies sehr deutlich ausdr\u00fccken. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Klassen und Strukturen sind nicht die einzige M\u00f6glichkeit, um das Handling von Daten zu strukturieren. Die Standardbibliothek stellt zudem eine ganze Menge Datencontainer f\u00fcr genau diese Zwecke zur Verf\u00fcgung. Mit std::tuple und std::array wurden in C++11 zwei Datenstrukturen mit zur Compile-Time bekannter Gr\u00f6\u00dfe eingef\u00fchrt. W\u00e4hrend std::array eine relativ simple Modernisierung von C-Arrays darstellt, wurde mit std::tuple eine generische M\u00f6glichkeit geschaffen, um heterogene Daten bequem im Programm herumzureichen, ohne dass der Programmiere reine Datenklassen oder structs erstellen muss.<\/p>\n Seit C++17 ist der Zugriff auf die Inhalte dieser Datenstrukturen durch die strukturierten Bindings sehr leichtgewichtig m\u00f6glich (s. Abbildung im\u00a0PDF<\/a>).<\/p>\n Zu beachten ist, dass alle Variablen hier dieselbe const-ness haben und entweder alle als Referenz oder By-Value gelesen werden. Die Structured Bindings funktionieren auch im Zusammenhang mit Klassen, allerdings ist dies etwas problematisch, da die Semantik von Klassenmembers keine starke Reihenfolge der Member vorsieht. Es gibt M\u00f6glichkeiten, diese Semantik zu reimplementieren, allerdings ist dies vergleichsweise aufw\u00e4ndig.<\/p>\n Einer der wohl am h\u00e4ufigsten verwendeten M\u00f6glichkeiten, f\u00fcr eigene Datentypen mit klaren Wertebereichen zu erstellen, waren schon in C die enums, und auch heute werden sie noch oft und gerne verwendet. Ein oft zitiertes dabei \u00c4rgernis ist, dass die Typensicherheit bei der Verwendung von Enums nur ungen\u00fcgend sichergestellt ist. So war es in der Vergangenheit m\u00f6glich, einen Wert eines Enum-Typs einer Variable eines anderen Enum-Typs zuzuweisen. Mit den neuen Standards geh\u00f6rt dies bei korrekter Verwendung der Vergangenheit an. Wird einer enum Definition das Keyword class oder struct hinzugef\u00fcgt, wird daraus ein stark typisierter Datentyp, und die Verwendung mit einem anderen enum-Typ f\u00fchrt je nach Konfiguration zu einer Warnung oder einem Fehler beim Kompilieren. Sozusagen als zus\u00e4tzlicher Bonus kann seit C++11 auch der unterliegende Datentyp f\u00fcr ein enum explizit angegeben werden, was der Portabilit\u00e4t des Codes zugute kommt. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Eine sehr h\u00e4ufige Verwendung von Daten mit klaren, aber nicht immer linearen Wertebereiten ist insbesondere bei Applikationen mit strikten Zeitanforderungen nat\u00fcrlich die Zeit selbst. Das Handling von Zeiteinheiten ist f\u00fcr viele Programmierer ein Albtraum. Die Gr\u00fcnde sind vielf\u00e4ltig, von der nicht-linearen Aufteilung von Sekunden, Minuten und Stunden bis hin dazu, dass schnell mal Verwirrung entsteht, um welche Zeiteinheit sich bei einem Aufruf wie sleep(100)handelt. Handelt es sich hier um Sekunden? Millisekunden? Mit der Einf\u00fchrung von std::chrono in C++11 und dem Hinzuf\u00fcgen von Zeitliteralen wird das Handling um einiges einfacher. Mit den Literalen k\u00f6nnen Zeitangaben mit einem einfachen Suffix im Code mit einer fixierten Einheit beziehungsweise mit einer fixen Aufl\u00f6sung deklariert werden. <chrono> liefert dabei alles zwischen Mikrosekunden und Stunden. Durch die Verwendung der von std::chrono mitgelieferten Zeiteinheiten lassen sich Zeitwerte bereits zur Compile-Time konvertieren, und das l\u00e4stige manuelle Umrechnen zur Laufzeit geh\u00f6rt der Vergangenheit an. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Auf den ersten Blick ist die Einf\u00fchrung direkten Initialisierung in if- und switch-Statements in C++17 eine M\u00f6glichkeit, Code noch ein kleines bisschen kompakter schreiben. Ein weiterer, etwas versteckter Vorteil ist, dass der Programmierer seine Absicht, dass ein Symbol nur innerhalb einer Verzweigung verwendet wird, deutlicher ausdr\u00fccken kann. Die Initialisierung direkt neben beziehungsweise in der Bedingung zu haben verhindert auch die Gefahr, dass sie bei Refactorings (unabsichtlich) von der Verzweigung getrennt wird. (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Im Zusammenhang mit den oben genannten Structured Bindings kann die direkte Initialisierung sehr elegant verwendet werden. Im folgenden Beispiel wird versucht, einen bereits existierenden Wert in einer std::map zu \u00fcberschreiben. Der R\u00fcckgabewert von insert wird direkt in einen Iterator und das Flag, ob die Operation erfolgreich war, entpackt und kann somit direkt innerhalb der Abfrage verwendet werden.<\/p>\n (s. Abbildung im\u00a0PDF<\/a>)<\/p>\n Wann immer ein Programmierer eine Annahme trifft, sollte dies im Code dokumentiert sein. Mit den Standardattributen k\u00f6nnen einige solcher Annahmen mit wenig Aufwand dokumentiert werden. Attribute sind seit l\u00e4ngerem f\u00fcr verschiedene Compiler bekannt, allerdings war die Notation f\u00fcr die verschiedenen Compiler oft unterschiedlich. Seit C++17 wurde diese als [[ attribute ]] standardisiert, was den Code lesbarer macht. Zudem wurden verschiedene, von allen Compilern unterst\u00fctzte Standardattribute eingef\u00fcgt, welche es dem Programmierer erlauben, seine Absichten f\u00fcr gewisse Konstrukte explizit zu formulieren:<\/p>\n Diese 10 kleinen Features und Funktionen sind nat\u00fcrlich nur ein kleiner Teil davon, was modernes C++ ausmacht. Aber durch deren konsequente Anwendung kann Code mit relativ wenig Aufwand lesbarer und einfacher Verst\u00e4ndlich gemacht werden, ohne dass die komplette Struktur einer existierenden Codebase gleich umgeschrieben werden muss.<\/p>\n Die Einf\u00fchrung der neuen Standards C++11\/14\/17 hat C++ merklich modernisiert. Nebst solchen gro\u00dfen Sprachfeatures wie smart-pointers, move semantics und varaidic templates gibt es auch noch eine ganze Menge an kleineren Erweiterungen, die oftmals unter dem Radar fliegen. Aber gerade diese Features k\u00f6nnen helfen, C++ Code merklich zu vereinfachen und wartbarer zu machen. Dies gekoppelt mit neuen Features in der STL kann helfen, viele kleine Fehlerchen schon beim Schreiben des Codes zu verhindern. Dass der Code sich dabei auch noch leichter liest und stabiler wird, sind weitere erfreuliche Nebeneffekte.<\/p>\n Dominik Berner ist ein Senior Software-Ingenieur bei der bbv Software Services AG mit einer Leidenschaft f\u00fcr modernes C++. Die Wartbarkeit von Code ist f\u00fcr ihn kein Nebeneffekt, sondern ein prim\u00e4res Qualit\u00e4tsmerkmal, das f\u00fcr die Entwicklung von langlebiger Software unabdingbar ist. Als Blogger und Speaker auf Konferenzen und Meetups wei\u00df er, wie Inhalte zu verpacken sind, damit f\u00fcr das Publikum ein Mehrwert entsteht.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Implementierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Implementierung\/\u00a0Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nModerner, wartbarer Code<\/h2>\n
Ein Beispiel zur Illustration<\/h2>\n
Vererbung kontrollieren mit override und final<\/h2>\n
using-Deklarationen und Konstruktorenvererbung<\/h2>\n
Weiterleiten von Konstruktoren<\/h2>\n
= delete – L\u00f6schen von Funktionen<\/h2>\n
Garantiertes verhindern von Kopien<\/h2>\n
Structured Bindings<\/h2>\n
Stark typisierte Enums<\/h2>\n
Zeit-Literale mit <chrono><\/h2>\n
Verzweigungen mit Initialisierung<\/h2>\n
Standardattribute<\/h2>\n
\n
\nZeigt an, dass eine Funktion nicht zur\u00fcckkehrt, z.B. weil sie immer eine Exception wirft<\/li>\n
\nZeigt an, dass die Verwendung dieser Klasse, Funktion oder Variable zwar erlaubt, aber nicht mehr empfohlen ist<\/li>\n
\nVerwendet in switch-Statement, um anzuzeigen, dass ein case:-block mit Absicht kein break beinhaltet<\/li>\n
\nProduziert eine Compiler-Warnung, falls ein so markierter R\u00fcckgabewert nicht verwendet wird<\/li>\n
\nUnterdr\u00fcckt Compiler-Warnungen bei nicht verwendeten Variablen. z.B. in Debug-Code <<\/li>\n<\/ul>\nFazit<\/h2>\n
Zusammenfassung<\/h2>\n
Autor<\/h2>\n
\nImplementierung – unsere Trainings & Coachings<\/h2>\n
\nImplementierung – Fachwissen<\/h2>\n