Mythen

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++.

 

Die Mythen

myths

Zuerst zu den Mythen rund um C++, mit denen ich mich immer wieder auseinandersetzen muss. Ich muss vorweg schicken. 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-Programmiereren 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 Implentierung der C++-Kersprache 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++ 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, besassen aber noch deutliches Optimierungspotential.
  • Ausbildungsdefizite
    • Zum einen lernen viele embedded Programmierer nur die Programmiersprache C, zum anderen verhindert der permante Zeitdruck sich auf ein neue Abenteuer einzulassen.
  • Verlust des Expertenstatus
    • Es ist schon ein mutiger Schritt für einen hoch geschätzen 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 am naheliegenstend, 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 Entwickerln mangelt es zum einen am Verständnis des klassischen C++98, zum anderne vor allem am Verständnis des modernen C++11.

     

Mir ist natürlich klar, dass ich mit einigen Aussagen dieses Artikels gehörig polarisiert habe. Wenn es aber der Sache dient, Interesse an den großartigen Feature 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.

 

 

 

 

 

 

title page smalltitle page small Go to Leanpub/cpplibrary "What every professional C++ programmer should know about the C++ standard library".   Hole dir dein E-Book. Unterstütze meinen Blog.

 

Mentoring

Stay Informed about my Mentoring

 

Rezensionen

Tutorial

Besucher

Heute 526

Gestern 2405

Woche 8732

Monat 36049

Insgesamt 3888763

Aktuell sind 38 Gäste und keine Mitglieder online

Kubik-Rubik Joomla! Extensions

Abonniere den Newsletter (+ pdf Päckchen)

Beiträge-Archiv

Sourcecode

Neuste Kommentare