Heute geht es um die zehn verbleibenden Regeln zur Performanz. Das hört sich nach einem sehr langen Artikel an, ist er aber nicht, da nur zwei Regeln einen Inhalt besitzen.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-4024280

In diesem Artikel geht meine Reise durch die Regeln zur Performanz in den C++ Core Guidelines weiter. Insbesondere beschäftige ich mich dem Softwareentwurf, der die Optimierung im Fokus hat.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-4012800.

Bevor ich über die Regeln zur Performanz schreibe, muss ich erst eine einfache Aufgabe erledigen: auf die Elemente eines Containers sukzessive zugreifen.

Heute schließe ich mit den verbleibenden Regeln zu Anweisungen ab. Dazu gibt es die sehr wichtigen Regeln zur Arithmetik. Werden diese nicht eingehalten, lauert undefiniertes Verhalten.

Hier geht es direkt zum Artikel auf Heise Developer.

Mein letzter Artikel zu den C++ Core Guidelines "To Switch or not to Switch, that is the Question" wurde sehr intensiv diskutiert. Der Einsatz einer Hashtabelle anstelle einer switch Anweisung scheint ein sehr emotionales Thema zu sein. Daher habe ich meinen ursprünglichen Plan geändert. Heute werde ich verschiedene Kontrollstrukturen vorstellen. Los geht es mit der if und switch Anweisung, weiter mit der Hashtabelle und zum Abschluss werde ich auf dynamischen und statischen Polymorphismus eingehen. Zusätzlich werde ich die verschiedenen Kontrollstrukturen bzgl. ihrer Pflege und Performanz vergleichen.

Zuerst einmal muss ich mich entschuldigen. Heute wollte ich meine Reise durch die C++ Core Guidelines mit den arithmetischen Ausdrücken fortsetzen. In meiner Schulung in dieser Woche gab es aber eine lange Diskussion zu switch Anweisungen in C/C++ und wie diese immer mehr unwartbar werden. Ehrlich gesagt, bin ich kein Freund von switch Anweisungen und ich verkünde gerne: Es gibt ein Leben nach switch Anweisungen.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-3985896

Bevor ich auf die gut 15 Regeln für Anweisungen eingehe, möchte ich gerne auf die zwei letzten Regeln für Ausdrücke eingehen. Beide Regeln helfen, das Programm vor undefinierten Verhalten zu bewahren.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-3977781.

Dieser Artikel geht auf einige Don'ts ein. Dies sind vor allem die zwei wichtigsten Regeln des Artikels: Setze std::move nicht unüberlegt ein und wende kein Slicing an. Und los geht's.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-3965137

Was haben Konvertierungen und Casts gemein? Sie sind sehr häufig die Ursache von Fehlern. Daher geht es nun um typische Fehler.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-3965134