Warum benötigen wir Richtlinien für modernes C++?

Dieser subjektive Blogbeitrag basiert auf den mehr als 15 Jahren Erfahrung als Trainer für C++, Python und der Softwareentwicklung im Allgemeinen. Zuletzt war ich für die Software auf Defibrillatoren verantwortlich. Dabei ging es auch um ihre Zulassung. Software dafür ist sehr herausfordernd, den im Fehlerfall steht das Leben oder die Gesundheit des Patienten auf dem Spiel.

In Pocket speichern vorlesen Druckansicht 33 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Rainer Grimm
Inhaltsverzeichnis

Dieser subjektive Blogbeitrag basiert auf den mehr als 15 Jahren Erfahrung als Trainer für C++, Python und der Softwareentwicklung im Allgemeinen. Zuletzt war ich für die Software auf Defibrillatoren verantwortlich. Dabei ging es auch um ihre Zulassung. Software dafür ist sehr herausfordernd, den im Fehlerfall steht das Leben oder die Gesundheit des Patienten auf dem Spiel.

Ich habe schon lange eine Frage, die wir als C++-Community beantworten sollten: Warum benötigen wir Richtlinien für modernes C++? Hier sind meine Gedanken dazu. Ich konzentriere mich nur auf drei Aspekte. Natürlich gibt es mehr.

C++ ist insbesondere für Novizen eine inhärent komplizierte Programmiersprache. Wer C++ lehrt, sollte einen Satz von Regeln lehren, die mindestens in 90 Prozent aller Anwendungsfälle richtig sind. Ich denke über Regeln nach wie "verwende auto", "initialisiere mit geschweiften Klammern", "ziehe Tasks Threads vor". Ich verwende die Regeln zunehmend in meinen Seminaren. Wir benötigen einen Kanon an bewährten Regeln. Sie sollten formulieren, wie Code zu schreiben ist.

Ich suche schon lange nach diesen Regeln. Daher habe ich bereits einige Präsentationen zu 10 Tipps gegeben, wie modernes C++ verwendet werden sollte. Zurzeit schreibe ich eine 10 Artikel lange Serie für das Linux-Magazin zu meinen Tipps. Ich verwendete als Startpunkt den "Zen of Python" von Tim Peters: Das sind 20 Aphorismen, wie idiomatisches Python geschrieben werden sollte.

Tatsächlich sind es nur 19 Regeln. Die letzte Regel wird immer noch gesucht.

Ich kann mich mit der Idee nicht anfreunden, dass jeder Trainer seine eigenen Regeln entwickelt. Im besten Fall wiederholen sich die Regeln. Im schlechtesten lehren wir verschiedene oder sogar widersprüchliche Regeln.

Ich mache mir nicht so sehr Sorgen über die Menge von neuen Featuren, die wir mit jedem neuen C++-Standard erhalten. Ich mache mir mehr Sorgen über die vielen neuen Konzepte, die modernes C++ unterstützen wird. Um ehrlich zu sein, das sind genau die herausfordernden Themen für professionelle Softwareentwickler. Er muss ihre Art, Probleme zu lösen, immer wieder in Frage stellen.Ich denke an eventbasierte Programmierung mit Coroutinen, Bedarfsauswertung, unendliche Datenstrukturen, Funktionskomposition oder Range Comprehension mit der neuen Ranges-Bibliothek. Oder Design by Contract, Reflektion oder mehr und mehr funktionale und mathematische Konzepte in C++ nach. Das ist bei weitem nicht alles. Concepts werden Templates revolutionieren.

Ich behaupte, dass die Plethora an neuen Konzepten insbesondere professionelle Programmierer fordern oder auch überfordern wird. Sie sind die Programmierer, die es gewohnt sind, ihre Probleme auf klassische Weise zu lösen. Ziemlich sicher werden sie in der Hammer-Nagel-Falle landen.

Ich habe ein weitere große Sorge. In der Embedded-Softwareentwicklung muss man sehr häufig MISRA C++ umsetzen. Die gültigen MISRA-C++:2008-Richtlinien wurden von der Motor Industry Software Reliability Association veröffentlicht. Sie basieren auf den MISRA-C-Richtlinien von 1998. Ursprünglich für die Automobilindustrie entworfen, wurden sie der Industriestandard für die Implementierung sicherheitskritischer Software in der Luftfahrt sowie im militärischen und den medizinischen Sektor. Entsprechend zu MISRA C beschreibt MISRA C++ Richtinien für eine sichere Teilmenge von C++. Wer MISRA C++ nicht kennt, in meinen Artikel "Fakten" gibt es Details.

Doch MISRA C++ besitzt ein konzeptionelles Problem. Wir sollen Richtlinien umsetzen, die von 2008 sind. Um es nochmals anders auszudrücken: Die Richtlinien repräsentieren nicht den Stand moderner Softwareentwicklung mit C++. Die Richtlinien sind drei Standards (einschließlich C++17) hinterher.

Ein einfaches Beispiel bringt das auf den Punkt: MISRA C++ verbietet das Überladen von Operatoren. Das ist nicht zeitgemäß. Ich schule in meinen Seminaren benutzerdefinierte Literale, um ein typsichere Arithmetik umzusetzen: auto constexpr dist = 4 * 5_m + 10_cm - 3_dm. Um diese typsichere Arithemetik zu implementieren, muss man die arithmetischen Operatoren und die Literal-Operatoren überladen. Hier gibt es die Details zu "benutzerdefinierten Literalen".

Um ehrlich zu sein. Ich glaube nicht, dass MISRA C++ wieder in den Gleichschritt mit dem aktuellen C++-Standard kommt. Meine Hoffnung ist eine andere.

Ich hoffe, dass die C++ Core Guideline, die ich bereits im Artikel "Was ist modernes C++" eingeführt habe, die Richtlinien für modernes C++ werden. Das bedeutet insbesondere, dass die C++ Core Guidlines langfristig die MISRA-C++-Richtlinien als einzuhaltenden Standard für C++ in sicherheitskritischen Systemen ersetzen.

Ich bin sehr gespannt auf eure Kommentare dazu.

Die Regeln der C++ Core Guidelines können nicht wie ein Buch gelesen werden. Ihre Absicht ist es, von Werkzeugen automatisch verarbeitet zu werden. Bevor ich aber ein Werkzeug verwende, möchte ich die Details kennen. Daher geht es im nächsten Artikeln mit den Details zu den C++ Core Guidelines los. ()