Grundlagen für C++ Professionals C++ in der Embedded-Programmierung: Mythen
Anbieter zum Thema
Als ich in der Embedded-Programmierung anfing, war ich verwundet, dass es so viele Vorbehalte gegen den Einsatz von C++ in der Embedded-Programmierung gibt. Die meisten basieren auf einem falschen Verständnis der Programmiersprache C++.

Zuerst zu den Mythen rund um C++, mit denen ich mich immer wieder auseinandersetzen muss. Ich muss vorwegschicken. Dieser Artikel spiegelt meine Wahrnehmung wider. Beispiele gefällig?
- Templates blähen den Code auf.
- Objekte müssen im Heap erzeugt werden.
- Exceptions sind teuer.
- C++ ist langsam und benötigt zu viel Speicher.
- C++ ist zu gefährlich in sicherheitskritischen Systemen.
- In C++ muss man objektorientiert programmieren.
- C++ kann man nur für Applikationen verwenden.
- Die iostream-Bibliothek ist zu groß, die STL-Bibliothek zu langsam.
Im Wesentlichen lässt sich die ganze Argumentation auf einen einfachen Nenner bringen.
=> C++ ist ein nettes Spielzeug. Wir beschäftigen uns hier aber mit den richtigen Problemen.
Die Liste der (Vor)urteile ist lang. Sie besteht aus Halbwahrheiten und Unwahrheiten, die meist von gestanden C-Programmierern vorgetragen werden. Ich will nur explizit auf die Unwahrheiten eingehen. Die Halbwahrheiten sind zum großen Teil eine Frage des richtigen Einsatzes der Sprachfeature von C++ und zum einen immer kleineren Teil Frage der Implementierung der C++-Kernsprache und ihrer Bibliotheken.
Objekte müssen im Heap erzeugt werden.
- Objekte lassen sich auf dem Stack erzeugen oder mit operator new an einer beliebigen Stelle in der Speicherstruktur anlegen.
C++ ist zu gefährlich in sicherheitskritischen Systemen.
- Natürlich ist eine Frage der Kompetenz des Entwicklers. Wer aber C-Strings mit C++-Strings, ein C-Array mit einem C++-Array oder einem std::vector vergleicht, Makros anstatt von konstanten Ausdrücken oder Templates gerne einsetzt, der kann wirklich nicht argumentieren, dass C++ zu gefährlich ist. Gerade in diesem Punkt sehe ich einen großen Vorteil von C++11.
In C++ muss man objektorientiert programmieren.
- C++ ist eine Multiparadigmen Programmiersprache. C++ erlaubt, objektorientiert, strukturiert, funktional, generisch oder auch generativ zu programmieren.
C++ kann man nur für Applikationen verwenden.
- C++ wird vom Feuerlöscher, über den Defibrillator bis hin zum Auto überall eingesetzt. ARM pflegt mit ARM GCC die aktuelle gcc-Kollektion von Compiler zusammen mit der gnu-Toolchain. Insbesondere steht dadurch der aktuelle g++ Compiler für C++ zur Verfügung. Dieses Paket, das immer häufiger nachgefragt wird, pflegt ARM für ihre Prozessor-Plattform, der Default-Architektur für die Embedded-Programmierung.
Woher kommen die Halbwahrheiten? Ich denke, es gibt viele Gründe.
Alte C++-Compiler
- Wissen, das auf den alten C++-Compiler basiert, die im letzten Jahrtausend verwendet wurden. Diese setzen zwar den C++-Standard richtig um, besaßen aber noch deutliches Optimierungspotential.
Ausbildungsdefizite
- Zum einen lernen viele Embedded-Programmierer nur die Programmiersprache C, zum anderen verhindert der permante Zeitdruck sich auf ein neues Abenteuer einzulassen.
Verlust des Expertenstatus
- Es ist schon ein mutiger Schritt für einen hoch geschätzten C-Experten, sich aus seiner Wohlfühlzone zu verabschieden und am nächsten Tag als C++-Anfänger aufzuwachen.
Bestehende Codebasis in C
- Typischerweise ist die bestehende Codebasis in C. Daher ist es natürlich naheliegend, einen Bug in C zu fixen oder ein neues Feature in C zu implementieren.
Viele C-Experten
- Es gibt viele C-Experten. Dies sind die Entwickler, die die Neuen einlernen und häufig aufgrund ihrer Erfahrung Führungsaufgaben besitzen.
Fluch der Monokultur
- Ich nehme die Embedded Programmierung häufig als Monokultur wahr. In ihr gibt es nicht die Variabilität der Werkzeuge, wie ich sie 15 Jahre im Consulting-Bereich für die Automobilindustrie erfahren haben. Während ich als Consultant gut 10 Programmiersprachen eingesetzt habe, reduziert sich die Anzahl meiner verwendeten Programmiersprachen im Embedded-Bereich auf drei.
Druck der Standards
- Es gibt viele Standards oder Regularien, die es in der Embedded-Programmierung umzusetzen gilt. Den Mut zur Innovation nehme ich indirekt proportional zum Druck der Standards und Regularien wahr.
Mangelndes Verständnis von C++
- Vielen Entwicklern mangelt es zum einen am Verständnis des klassischen C++98, zum anderen vor allem am Verständnis des modernen C++11.
Mir ist klar, dass ich mit einigen Aussagen dieses Artikels gehörig polarisiert habe. Wenn es aber der Sache dient, Interesse an den großartigen Features für die C++ Entwicklung in der Embedded-Programmierung zu wecken, will ich mich gern dem Gegenwind stellen. Im nächsten Artikel werde ich den Mythen die Fakten gegenüberstellen. Wertvolle Hilfe wird mir der Technical Report on C++ Performance geben, der auf klassischem C++ (C++98) basiert.
Mehr Informationen zu allen Themen rund um C++ finden und zum Mentoring für C++ Sie auf dem Blog von Rainer Grimm.
Ein Kompaktseminar zum Thema Concurreny in modernem C++ sowie Vorträge zu den Themen "Was Sie über Concurreny in modernem C++ wissen müssen" sowie "Die vielen Varianten von Konstantheit in modernem C++" können Sie auf dem ESE-Kongress erleben.
(mbf)
* Rainer Grimm ist seit vielen Jahren als Softwarearchitekt, Team- und Schulungsleiter tätig. In seiner Freizeit schreibt er gerne Artikel zu den Programmiersprachen C++, Python und Haskell, spricht aber auch gerne auf Fachkonferenzen. Auf seinem Blog Modernes C++ (heise Developer) beschäftigt er sich intensiv mit seiner Leidenschaft C++. Seit 2016 steht er auf selbstständigen Beinen. Insbesondere das Vermitteln von Wissen zu modernem C++ ist ihm eine Herzensangelegenheit. Seine Bücher "C++11 für Programmierer", "C++" und "C++-Standardbibliothek" für die "kurz und gut"-Reihe sind beim Verlag O'Reilly erschienen. Seine englischsprachigen Werke "The C++ Standard Library", "Concurrency with Modern C++" und "C++20" sind in mehrere Sprachen übersetzt worden. Im April erscheint sein englischsprachiges Buch zu den "C++ Core Guidelines" bei Addison-Wesley.
(ID:48655120)