Ein Angebot von

C und C++ in einer Embedded-Anwendung mischen

| Autor / Redakteur: Colin Walls * / Sebastian Gerstl

Will man in C geschriebenen Legacy Code beibehalten, aber Embedded-Anwendungen modernisieren, scheint es oft praktischer, die Programmiersprachen C und C++ gemeinsam zu verwenden. Wie lässt sich unterschiedlicher Code sinnvoll mischen und auf was für Probleme muss man dabei achten?
Will man in C geschriebenen Legacy Code beibehalten, aber Embedded-Anwendungen modernisieren, scheint es oft praktischer, die Programmiersprachen C und C++ gemeinsam zu verwenden. Wie lässt sich unterschiedlicher Code sinnvoll mischen und auf was für Probleme muss man dabei achten? (Bild: gemeinfrei / CC0)

Viele Embedded-Anwendungen sind noch in C geschrieben, doch immer mehr Entwickler programmieren inzwischen in C++. In einigen Applikationen werden sogar beide Sprachen gemeinsam verwendet. Ist das sinnvoll?

C ist die am weitesten verbreitete Programmiersprache in Embedded-Anwendungen. Seit vielen Jahren wird zwar ein Wechsel zu C++ erwartet, der Umstieg erfolgt jedoch recht langsam. Viele Entwickler denken jedoch darüber nach oder planen ihn. C++ ist im Wesentlichen eine Obermenge von C. Deshalb können die beiden Sprachen durchaus gemischt werden.

Obwohl der Mix von C und C++ möglich ist, stellen sich drei Fragen:

  • Warum sollte man das machen?
  • Wie macht man das?
  • Gibt es irgendwelche Nachteile oder Probleme?

Warum sollte man C– und C++–Code in einer Embedded-Anwendung mischen?

Die kurze Antwort ist Legacy-Code. Ein neues Projekt wird selten ganz von vorne angefangen. Falls doch, könnten Entwickler durchaus alles in C++ schreiben.

Der vernünftigere Ausgangspunkt und viel wahrscheinlicher ist jedoch die Wiederverwendung von bestehendem Code, sei er von einer internen oder externen Quelle. Und dieser Code ist C. Um also mit C++ voranzukommen, ist eine Mischung der beiden Sprachen fast unvermeidlich.

Wie lässt sich C– und C++–Code mischen?

Es gibt zwei grundlegende Möglichkeiten für die Koexistenz von C und C++:

Ansatz A: Der naheliegende Weg zum Mischen von Code besteht darin, jedes Modul einfach mit seinem eigenen Compiler zu kompilieren und dann alle Objektmodule miteinander zu verbinden. Dies führt jedoch unmittelbar zu einem Problem: Es werden Link-Fehler gemeldet. Das liegt daran, dass der C++-Compiler die Namen von Funktionen ändert, was als „mangling“ bezeichnet wird.

Mit derartigen Änderungen werden eindeutige Namen generiert, die aus einer Kombination aus der ursprünglichen Kennung sowie aus der Anzahl und dem Typ der Funktionsparameter bestehen. Das hat zwei Gründe: Erstens, Verknüpfungsfehler entstehen, wenn Funktionsdeklarationen, Definitionen und Aufrufe nicht übereinstimmen. [Dies nennt man „typesafe linkage“.] Zweitens, es erleichtert das Überladen von Funktionen, bei denen zwei Funktionen den gleichen Namen haben, aber unterschiedliche Parameterkombinationen aufweisen; „mangling“ macht jeden Namen einzigartig.

Dieses Problem lässt sich mit einem externen C-Konstrukt lösen. Die Deklaration einer C++-Funktion mit diesem Qualifier bedeutet, dass ihr Name nicht verändert wird. Die Anwendung für eine externe Deklaration einer C-Funktion stellt sicher, dass der C++-Compiler keine Aufrufe der Funktion verwaltet.

Ansatz B: Die Alternative besteht darin, den C-Code mit dem C++-Compiler zu kompilieren, das heißt, ihn so zu behandeln, als wäre er C++-Code. Dies würde nahtlos funktionieren, wenn C eine echte Teilmenge von C++ wäre. Tatsächlich ist jedoch große Sorgfalt geboten, um den Code zu „bereinigen“ und sicherzustellen, dass er wirklich kompatibel ist.

Gibt es Nachteile beim Mischen von C- und C++-Code?

Es gibt nur sehr wenige Nachteile beim Mischen der beiden Sprachen. Bei Ansatz A gibt es das Problem, dass die Type-Safe-Verknüpfung verloren geht. Dies gilt aber nur für C-Funktionen, die aus C++ aufgerufen werden oder umgekehrt. Andere C++-Funktionen sind davon nicht betroffen. Natürlich können die gemeinsamen Funktionen nicht überladen werden.

Langfristig ist die Anwendung von Ansatz B besser, da der einmal bereinigte Code als C++ behandelt werden kann und Funktionen der Sprache verwendet werden können.

Wie bereits erwähnt, ist der Bereinigungsprozess nicht trivial. Deshalb müssen das Kosten-Nutzen-Verhältnis des Aufwands und die Wahrscheinlichkeit einer zukünftigen Verwendung von Legacy-Code gegeneinander abgewogen werden.

Der Autor

Colin Walls, Embedded-Software-Technologist bei Mentor, a Siemens business.
Colin Walls, Embedded-Software-Technologist bei Mentor, a Siemens business. (Bild: Caroline Mann)

* Colin Walls verfügt über fast 40 Jahre Erfahrung in der Elektronikindustrie, hauptsächlich im Bereich Embedded Software. Er ist Embedded-Software-Technologist bei Mentor, a Siemens business, mit Sitz in Großbritannien. Walls hält regelmäßig Vorträge auf Konferenzen und Seminaren. Zudem ist er Autor zahlreicher Fachartikel sowie zweier Bücher über Embedded Software und betreibt ein Blog auf http://blogs.mentor.com/colinwalls.

Fünf praxisnahe C/C++-Tipps für Embedded-Software-Programmierer

Fünf praxisnahe C/C++-Tipps für Embedded-Software-Programmierer

07.01.19 - Es ist Zeit für ein paar weitere, hoffentlich hilfreiche Tipps für Embedded-Software-Entwickler. Diese Tipps sind in vielen Fällen nur gesunder Menschenverstand, aber ich denke, wir müssen sie uns immer mal wieder in Erinnerung rufen. lesen

C++ für Echtzeit-Anwendungen

C++ für Echtzeit-Anwendungen

24.05.19 - Die Objektorientierte Programmierung in C++ hat unter vielen Embedded-Programmierern den Ruf, gegenüber der Strukturierten Programmierung in C weniger performant zu sein. Hierdurch wird C++ für zur Erreichung harter Echtzeit meist von vornherein ausgeschlossen. Aber ist das auch berechtigt? lesen

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 46007363 / Implementierung)