C oder C++: woran ihr die Sprache im hardwarenahen Projekt festmacht
Beide übersetzen ohne Laufzeitunterbau auf Maschinencode. Auseinander gehen sie bei dem, was der Compiler prüft, und bei dem, was euer Team dauerhaft beherrschen muss.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Frage wird fast immer als Glaubensfrage gestellt
Der Anlass ist meistens ein neues Gerät oder eine neue Schicht auf einer bestehenden Firmware, und die Diskussion beginnt bei Geschwindigkeit und Speicherbedarf. Genau dort gibt es aber am wenigsten zu holen. Beide Sprachen gehen in den verbreiteten Werkzeugketten durch dieselbe Codeerzeugung, beide brauchen keine virtuelle Maschine und keine Speicherbereinigung zur Laufzeit, und ein C++-Programm, das dieselben Operationen ausführt wie ein C-Programm, ist am Ende dieselbe Menge Maschinencode. Wer die Entscheidung an Zahlen aus einem kleinen Messprogramm festmacht, hat die Frage nicht beantwortet, sondern nur verschoben.
Teuer wird die Sache an zwei anderen Stellen. Die erste ist der Sprachumfang. C ist in einer Woche lesbar und nach einem Jahr noch nicht ausgereizt, C++ ist in einer Woche nicht lesbar und nach zehn Jahren noch nicht ausgereizt. Ein Team, das C++ ohne vereinbarte Teilmenge einsetzt, hat nach zwei Jahren drei Dialekte im selben Repository, und jedes Review beginnt mit der Frage, welcher davon an dieser Stelle gilt. Die zweite Stelle ist die Fehlerklasse. In C schreibt ihr die Speicherverwaltung von Hand, und jede Zeile, an der ein Zeiger die Besitzverhältnisse wechselt, ist eine Zeile, an der ein Mensch aufpassen muss.
Die brauchbare Fragestellung lautet deshalb nicht, welche Sprache besser ist, sondern: Was gibt die Zielplattform vor, welches Regelwerk müsst ihr einhalten, wie viel Bestandscode hängt dran, und wie viel Sprachumfang könnt ihr im Team dauerhaft durchsetzen? Diese vier Antworten entscheiden die Sache in den meisten Projekten, bevor über ein einziges Sprachfeature gesprochen wird.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
C und C++ an denselben Kriterien
Verglichen wird hier C nach aktuellem Standard mit einem C++, für das im Projekt eine Teilmenge vereinbart ist. Ein C++ ohne solche Vereinbarung schneidet in fast jedem Punkt schlechter ab als beide Spalten.
C
kleiner Sprachkern, Speicherverwaltung von Hand, aktueller Standard C23 als ISO/IEC 9899:2024, Werkzeugkette für praktisch jede Zielarchitektur
C++
Typsystem, Ressourcenbindung an Objektlebensdauer und Auswertung zur Übersetzungszeit, dafür ein Sprachumfang, den niemand vollständig beherrscht
| Entscheidungsfrage | C | C++ |
|---|---|---|
| Wie viel fängt der Compiler ab, bevor das Programm überhaupt läuft? | Schwäche Der Compiler kennt keine Besitzverhältnisse, wandelt zwischen Zeigertypen bereitwillig um und sieht einer Funktion nicht an, ob der Aufrufer den zurückgegebenen Speicher freigeben muss. Ob ein Puffer lang genug ist und ob ein Zeiger noch auf gültige Daten zeigt, steht nirgends im Programm, sondern nur im Kopf der Leute, die es schreiben. | Stärke Destruktoren geben Ressourcen frei, sobald der Gültigkeitsbereich endet, unique_ptr macht die Besitzfrage zu einer Eigenschaft des Typs, enum class und eigene Wertetypen verhindern vertauschte Argumente, und Container kennen ihre eigene Länge. Das sind Prüfungen, die in C ausschließlich ein Mensch leisten kann. |
| Was kostet ein Sprachfeature an Laufzeit und an Platz im Flash? | Stärke Es passiert nichts, was nicht im Quelltext steht. Diese Berechenbarkeit ist der Grund, warum C in Bereichen mit wenigen Kilobyte Speicher und harten Fristen die Voreinstellung geblieben ist, und warum sich der Blick in das erzeugte Assembler lohnt und auch lohnend bleibt. | Kommt darauf an Der größte Teil der Sprache kostet nichts, was eine handgeschriebene C-Entsprechung nicht auch kostet. Drei Bereiche fallen aus der Zusage heraus: Ausnahmen, Laufzeit-Typinformation und die Ein- und Ausgabeströme der Standardbibliothek. Sind sie über die passenden Compilerschalter abgeschaltet, liegen beide Sprachen wieder in derselben Größenordnung. |
| Wie schnell versteht jemand fremden Code? | Stärke Der Sprachkern ist klein genug, dass ein Aufruf ein Aufruf bleibt und an einer Zeile genau das passiert, was dort steht. Der Preis dafür sind deutlich mehr Zeilen für dieselbe Aussage und eine Menge wiederkehrender Kleinarbeit, die niemand liest und in der sich Fehler gut verstecken. | Schwäche Ein Semikolon kann einen Destruktor auslösen, ein Operator kann eine Funktion sein, ein Argument kann still umgewandelt werden, und dasselbe Template bedeutet für jeden Typ etwas anderes. In einem eingespielten Team mit vereinbartem Stil ist das kein Problem, für neue Leute verlängert es die Einarbeitung erheblich. |
| Welche Regelwerke und qualifizierten Werkzeuge stehen bereit? | Stärke MISRA C ist seit Jahrzehnten der Bezugspunkt für sicherheitsgerichtete Entwicklung, aktuell in der Fassung MISRA C:2025 mit 22 Direktiven und 201 Regeln. Prüfwerkzeuge, qualifizierte Compiler und Erfahrung bei den Prüfstellen sind entsprechend breit vorhanden. | Kommt darauf an Mit MISRA C++:2023 gibt es seit Oktober 2023 wieder genau einen Bezugspunkt: Das Dokument zielt auf C++17 und hat die früheren AUTOSAR-C++14-Richtlinien aufgenommen, die vorher parallel dazu standen. Die Sache ist damit geordnet, die Erfahrungsbasis in Projekten und bei Prüfstellen ist aber jünger als auf der C-Seite. |
| Wie gut kommt ihr an fremden Code und fremde Schnittstellen heran? | Stärke Die C-Schnittstelle ist die gemeinsame Sprache zwischen allem. Betriebssystemkerne, Hersteller-SDKs für Feldbus, Kameras und Antriebe, Skriptsprachen und praktisch jede Fremdbibliothek sprechen sie, und ein C-Modul lässt sich überall einhängen, ohne dass jemand einen Wrapper schreibt. | Stärke C++ ruft C-Bibliotheken direkt auf und legt eine eigene Bibliothekswelt darüber, von der Standardbibliothek über Boost bis zu Qt, OpenCV und Eigen. In die andere Richtung braucht ein C-Aufrufer einen Wrapper mit extern C, weil Name Mangling und Ausnahmen sonst nicht zusammenpassen. |
| Wie besetzt ihr eine Stelle und wie lang ist die Einarbeitung? | Kommt darauf an Wer C wirklich beherrscht, hat es meistens hardwarenah gelernt, und dieser Kreis wächst nicht. Dafür ist die Sprache so klein, dass jemand mit Programmiererfahrung sie in überschaubarer Zeit lesen kann; die Fallstricke liegen in der Bibliothek und im undefinierten Verhalten, nicht in der Syntax. | Kommt darauf an Der Bewerberkreis ist größer, die Spannbreite dessen, was jemand unter C++ versteht, allerdings auch. Ohne eine im Projekt vereinbarte Teilmenge dauert es lange, bis neue Leute im selben Stil schreiben wie der Rest, und Reviews drehen sich dann um Stil statt um Fachlichkeit. |
Wie viel fängt der Compiler ab, bevor das Programm überhaupt läuft?
Der Compiler kennt keine Besitzverhältnisse, wandelt zwischen Zeigertypen bereitwillig um und sieht einer Funktion nicht an, ob der Aufrufer den zurückgegebenen Speicher freigeben muss. Ob ein Puffer lang genug ist und ob ein Zeiger noch auf gültige Daten zeigt, steht nirgends im Programm, sondern nur im Kopf der Leute, die es schreiben.
Destruktoren geben Ressourcen frei, sobald der Gültigkeitsbereich endet, unique_ptr macht die Besitzfrage zu einer Eigenschaft des Typs, enum class und eigene Wertetypen verhindern vertauschte Argumente, und Container kennen ihre eigene Länge. Das sind Prüfungen, die in C ausschließlich ein Mensch leisten kann.
Was kostet ein Sprachfeature an Laufzeit und an Platz im Flash?
Es passiert nichts, was nicht im Quelltext steht. Diese Berechenbarkeit ist der Grund, warum C in Bereichen mit wenigen Kilobyte Speicher und harten Fristen die Voreinstellung geblieben ist, und warum sich der Blick in das erzeugte Assembler lohnt und auch lohnend bleibt.
Der größte Teil der Sprache kostet nichts, was eine handgeschriebene C-Entsprechung nicht auch kostet. Drei Bereiche fallen aus der Zusage heraus: Ausnahmen, Laufzeit-Typinformation und die Ein- und Ausgabeströme der Standardbibliothek. Sind sie über die passenden Compilerschalter abgeschaltet, liegen beide Sprachen wieder in derselben Größenordnung.
Wie schnell versteht jemand fremden Code?
Der Sprachkern ist klein genug, dass ein Aufruf ein Aufruf bleibt und an einer Zeile genau das passiert, was dort steht. Der Preis dafür sind deutlich mehr Zeilen für dieselbe Aussage und eine Menge wiederkehrender Kleinarbeit, die niemand liest und in der sich Fehler gut verstecken.
Ein Semikolon kann einen Destruktor auslösen, ein Operator kann eine Funktion sein, ein Argument kann still umgewandelt werden, und dasselbe Template bedeutet für jeden Typ etwas anderes. In einem eingespielten Team mit vereinbartem Stil ist das kein Problem, für neue Leute verlängert es die Einarbeitung erheblich.
Welche Regelwerke und qualifizierten Werkzeuge stehen bereit?
MISRA C ist seit Jahrzehnten der Bezugspunkt für sicherheitsgerichtete Entwicklung, aktuell in der Fassung MISRA C:2025 mit 22 Direktiven und 201 Regeln. Prüfwerkzeuge, qualifizierte Compiler und Erfahrung bei den Prüfstellen sind entsprechend breit vorhanden.
Mit MISRA C++:2023 gibt es seit Oktober 2023 wieder genau einen Bezugspunkt: Das Dokument zielt auf C++17 und hat die früheren AUTOSAR-C++14-Richtlinien aufgenommen, die vorher parallel dazu standen. Die Sache ist damit geordnet, die Erfahrungsbasis in Projekten und bei Prüfstellen ist aber jünger als auf der C-Seite.
Wie gut kommt ihr an fremden Code und fremde Schnittstellen heran?
Die C-Schnittstelle ist die gemeinsame Sprache zwischen allem. Betriebssystemkerne, Hersteller-SDKs für Feldbus, Kameras und Antriebe, Skriptsprachen und praktisch jede Fremdbibliothek sprechen sie, und ein C-Modul lässt sich überall einhängen, ohne dass jemand einen Wrapper schreibt.
C++ ruft C-Bibliotheken direkt auf und legt eine eigene Bibliothekswelt darüber, von der Standardbibliothek über Boost bis zu Qt, OpenCV und Eigen. In die andere Richtung braucht ein C-Aufrufer einen Wrapper mit extern C, weil Name Mangling und Ausnahmen sonst nicht zusammenpassen.
Wie besetzt ihr eine Stelle und wie lang ist die Einarbeitung?
Wer C wirklich beherrscht, hat es meistens hardwarenah gelernt, und dieser Kreis wächst nicht. Dafür ist die Sprache so klein, dass jemand mit Programmiererfahrung sie in überschaubarer Zeit lesen kann; die Fallstricke liegen in der Bibliothek und im undefinierten Verhalten, nicht in der Syntax.
Der Bewerberkreis ist größer, die Spannbreite dessen, was jemand unter C++ versteht, allerdings auch. Ohne eine im Projekt vereinbarte Teilmenge dauert es lange, bis neue Leute im selben Stil schreiben wie der Rest, und Reviews drehen sich dann um Stil statt um Fachlichkeit.
Was passt wann
- Wenn Zielplattform, Herstellerwerkzeuge oder ein bestehender Kern die Sprache ohnehin festlegen
- nehmt diese Sprache und steckt den freigewordenen Aufwand in statische Analyse und ein verbindliches Regelwerk, statt die Entscheidung noch einmal aufzurollen.
- Wenn ihr neu anfangt, Ressourcen verwaltet werden müssen und ein gepflegter C++-Compiler für die Zielplattform vorhanden ist
- nehmt C++, legt vor der ersten Zeile fest, welche Teilmenge gilt, und schaltet Ausnahmen, Laufzeit-Typinformation und dynamische Speicheranforderung dort ab, wo sie nicht hingehören.
- Wenn im Team niemand über den C++-Grundkurs hinaus geführt hat und der Terminplan keine Lernkurve verträgt
- bleibt bei C und holt euch die fehlende Prüfung über statische Analyse, Sanitizer im Bauprozess und ein schriftliches Regelwerk zurück.
Fünf Prüfungen, und die Sprachfrage ist entschieden
- 01 Schreibt die Zielplattform oder die Werkzeugkette des Herstellers die Sprache vor? Dann endet die Diskussion hier.
- 02 Gibt es Bestandscode, an den ihr anschließt? Die Grenze zwischen alt und neu ist der teure Teil.
- 03 Welches Regelwerk gilt bei euch, MISRA C oder MISRA C++? Beides zusammen gibt es nicht.
- 04 Könnt ihr eine C++-Teilmenge schriftlich festlegen und im Bauprozess durchsetzen?
- 05 Wie viele Fehler des letzten Jahres hingen an Speicher, Lebensdauer und Besitzverhältnissen?
Was nach dieser Seite auf dem Tisch liegt
Die Abwägung besteht aus sechs Prüfungen, die sich an vorhandenen Unterlagen beantworten lassen: am Datenblatt der Zielplattform, am Fehlerverzeichnis, am geltenden Regelwerk und an den Leuten, die den Code später pflegen. Erst wenn diese sechs kein eindeutiges Bild ergeben, wird es zur Geschmacksfrage.
Die harten Vorgaben zuerst abräumen
Prüf, ob der Hersteller eurer Zielplattform überhaupt einen gepflegten C++-Compiler liefert, ob ein Betriebssystem oder eine Plattform die Sprache festlegt und ob es einen Kern gibt, an den ihr anschließt. In vielen Projekten ist die Entscheidung nach diesem Schritt bereits gefallen.
Das Zero-Overhead-Versprechen richtig lesen
Der Satz besagt, dass ihr für ein Sprachfeature nichts bezahlt, das ihr nicht benutzt, und dass ein benutztes Feature nicht teurer ist als eine handgeschriebene Entsprechung. Er besagt nicht, dass alles gratis ist. Drei Bereiche fallen aus dieser Zusage heraus, und die kannst du benennen.
Den Sprachumfang als Projektentscheidung behandeln
Leg schriftlich fest, was im Projekt erlaubt ist, und setz es über Compilerschalter und statische Analyse durch, statt es in Reviews immer wieder neu auszuhandeln. Ohne diesen Schritt verliert C++ jeden Vorteil, den es gegenüber C hat.
Die Fehlerklasse beziffern statt sie zu diskutieren
Geh die Fehler des letzten Jahres durch und zähl, wie viele davon an Speicher, Lebensdauer oder Besitzverhältnissen hingen. Diese Zahl sagt dir, wie viel euch die zusätzliche Prüfung durch das Typsystem wert sein sollte.
Die Regelwerke auseinanderhalten
Für C und für C++ gibt es jeweils ein eigenes, aktuell gepflegtes MISRA-Dokument. Beides gleichzeitig auf dieselbe Codebasis anzuwenden ergibt keinen Sinn, und die Wahl des Regelwerks entscheidet mit darüber, welche Prüfwerkzeuge und welche Compiler infrage kommen.
Den gemischten Betrieb von Anfang an planen
Fast jedes reale Projekt enthält beides. Du weißt danach, wo die Schnittstelle zwischen den Sprachen verläuft, warum sie eine C-Schnittstelle sein muss und was über diese Grenze nicht hinüberdarf.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was beide Sprachen gemeinsam haben und wo die Standards stehen
Beide Sprachen übersetzen direkt auf Maschinencode, brauchen keine virtuelle Maschine, keinen Zwischencode und keine Speicherbereinigung zur Laufzeit. In den verbreiteten Werkzeugketten teilen sie sich sogar die Codeerzeugung, weil GCC und Clang für C und C++ dieselbe Optimierungs- und Ausgabestufe benutzen. Unterschiede in der Laufzeit echter Programme entstehen deshalb fast nie an der Sprache, sondern am Speicherlayout, an unnötigen Kopien und am Ein- und Ausgabeverhalten.
Bei den Standards ist die Lage geordnet. Für C ist C23 die aktuelle Fassung, formal ISO/IEC 9899:2024, veröffentlicht am 31. Oktober 2024. Für C++ ist C++23 der aktuell veröffentlichte Standard, formal ISO/IEC 14882:2024, und die Arbeit an C++26 läuft im zuständigen Gremium. Für eure Entscheidung ist das eher eine Randnotiz, denn in sicherheitsgerichteten Projekten kommt selten die neueste Fassung zum Einsatz, sondern die, für die es einen qualifizierten Compiler und ein passendes Regelwerk gibt.
Verschoben hat sich in den letzten Jahren vor allem der Druck von außen. Sicherheitsbehörden mehrerer Länder haben unter Federführung von CISA und NSA eine gemeinsame Empfehlung veröffentlicht, in der Speicherfehler als die häufigste Klasse offengelegter Schwachstellen benannt werden und Hersteller aufgefordert sind, einen schriftlichen Plan für speichersichere Entwicklung vorzulegen. Das macht weder C noch C++ unbrauchbar, es verschiebt aber die Beweislast: Ihr müsst inzwischen erklären können, wie ihr genau diese Fehlerklasse in den Griff bekommt, und diese Erklärung fällt mit C++ und einem konsequent genutzten Typsystem leichter als mit rohen Zeigern.
Was C++ dazulegt, ohne dass es zur Laufzeit kostet
Hinter dem größten Teil des Gewinns steckt ein einziges Muster: Eine Ressource wird an die Lebensdauer eines Objekts gebunden. Das Objekt übernimmt beim Anlegen einen Speicherblock, eine Dateikennung, eine Sperre oder einen Anschluss und gibt ihn frei, sobald sein Gültigkeitsbereich endet. Das passiert auch dann, wenn die Funktion an einer unerwarteten Stelle verlassen wird. In C ist das Gegenstück eine Kette von Sprungmarken am Ende der Funktion, die jemand pflegen und in jeden neuen Fehlerpfad mitziehen muss. Genau dort entstehen die Lecks, die im Labor nie auffallen und nach drei Wochen Dauerbetrieb das Gerät lahmlegen.
Der zweite Block betrifft das Typsystem. Ein Aufzählungstyp mit enum class lässt sich nicht mehr versehentlich als Zahl behandeln, ein eigener Wertetyp für Millimeter und einer für Zoll lassen sich nicht mehr vertauschen, ein Container kennt seine Länge, und eine Sicht auf einen Speicherbereich trägt diese Länge mit sich, statt sie als zweiten Parameter danebenzustellen. Jede dieser Kleinigkeiten nimmt genau die Fehler aus dem Review heraus, die dort am unzuverlässigsten gefunden werden, weil sie unauffällig aussehen.
Der dritte Block ist die Auswertung zur Übersetzungszeit. Was mit constexpr ausgerechnet wird, steht danach als Konstante im Programm und kostet zur Laufzeit gar nichts. Tabellen, Umrechnungsfaktoren und Prüfsummen über feste Daten lassen sich damit lesbar im Quelltext hinschreiben, statt sie in einem Skript zu erzeugen und als generierte Datei einzuchecken, die irgendwann nicht mehr zum Erzeuger passt. Templates übernehmen dabei die Rolle, die in C die Makros spielen, mit dem entscheidenden Unterschied, dass der Compiler die Typen sieht und den Fehler an der Stelle meldet, an der er steht.
Wo C++ tatsächlich kostet und wie ihr das eingrenzt
Ausnahmen sind der auffälligste Posten. Sie brauchen Tabellen im Binärabbild, und der Zeitbedarf beim Werfen hängt vom Aufrufstapel ab, lässt sich also nicht als feste obere Schranke angeben. In Systemen mit harten Fristen ist das ein Ausschlussgrund, und deshalb laufen viele hardwarenahe Projekte mit abgeschalteten Ausnahmen. An ihre Stelle treten Rückgabewerte, die Ergebnis oder Fehler transportieren. Wichtig ist, diese Entscheidung früh zu treffen, denn Teile der Standardbibliothek melden Fehler ausschließlich über Ausnahmen und fallen mit dem Schalter weg.
Der zweite Posten ist die Laufzeit-Typinformation samt dynamic_cast, der dritte sind die Ein- und Ausgabeströme der Standardbibliothek, die den Formatierungsapparat mit ins Binärabbild ziehen und dort schnell zweistellige Kilobyte belegen. Beides ist verzichtbar. Virtuelle Funktionen gehören ausdrücklich nicht in diese Liste: Ein virtueller Aufruf ist ein Sprung über eine Tabelle und damit ungefähr so teuer wie der Zeiger auf eine Funktion, den ihr in C an derselben Stelle von Hand hinschreiben würdet.
Zwei Nebenwirkungen gehören trotzdem auf den Zettel. Templates werden für jeden verwendeten Typ neu übersetzt, das lässt Binärdatei und Bauzeit wachsen, wenn niemand darauf achtet, und ein fertiges Werkzeug zum Nachmessen gibt es hier nicht, dafür die Größenauswertung des Linkers. Und die dynamische Speicheranforderung ist auf einem Gerät mit wochenlanger Laufzeit ein Risiko für sich, unabhängig von der Sprache: Ein Heap, der nach drei Wochen keinen zusammenhängenden Block mehr findet, erzeugt einen Fehler, den niemand im Labor reproduziert. Container mit fester Kapazität und Pool-Allokatoren sind die übliche Antwort, und sie funktionieren in C++ genauso wie die statischen Puffer in C, nur mit Typprüfung.
Regelwerke, Werkzeugqualifizierung und die Frage nach der Zulassung
Für C ist MISRA C:2025 vom März 2025 die aktuelle Fassung, mit 22 Direktiven und 201 Regeln. Sie folgt auf MISRA C:2023, das seinerseits MISRA C:2012 mit allen Ergänzungen und Berichtigungen zusammengeführt hatte. Wer heute ein Projekt aufsetzt, greift zur aktuellen Fassung, und wer ein bestehendes Projekt gegen eine ältere prüft, sollte den Umstieg als eigenen Vorgang planen, weil sich Regelnummern und Klassifizierungen zwischen den Fassungen bewegt haben.
Für C++ ist die Lage seit Kurzem einfacher als früher. MISRA C++:2023 erschien im Oktober 2023, zielt auf C++17 und hat die AUTOSAR-C++14-Richtlinien aufgenommen, die zuvor als zweites Regelwerk daneben standen und in Automobilprojekten regelmäßig zu der Frage geführt haben, welches von beiden nun gilt. Diese Doppelung ist damit erledigt. Umgekehrt heißt das aber auch: Wenn eure Zielplattform noch auf C++14 festgelegt ist, prüft, was das für die Anwendbarkeit des Regelwerks bedeutet.
Der Punkt, an dem die Sprachfrage im regulierten Umfeld tatsächlich Geld kostet, ist die Werkzeugkette. ISO 26262 in der Fassung von 2018 umfasst zwölf Teile; Teil 6 behandelt die Softwareentwicklung, Teil 8 die unterstützenden Prozesse und darin auch die Qualifizierung eingesetzter Werkzeuge. Ein Compiler ist ein solches Werkzeug, denn er kann Fehler einbringen, die im Quelltext nicht stehen. Qualifizierte Compiler gibt es nicht für jede Kombination aus Sprache, Sprachstandard und Zielarchitektur, und die Auswahl ist auf der C-Seite deutlich größer. Diese Frage gehört an den Anfang der Entscheidung und ins Gespräch mit dem Qualitätswesen, nicht in die Woche vor der Abnahme.
Beide Sprachen in einem Projekt
In der Realität stellt sich die Frage selten als Entweder-oder, sondern als Grenzverlauf. Der übliche Aufbau setzt Startcode, Treiber und alles, was der Hersteller mitliefert, in C und legt die Anwendungsschicht in C++ darüber. Umgekehrt kommt genauso vor: Ein gewachsenes C-System bleibt unangetastet, und neue Module entstehen in C++ und werden über eine schmale Schnittstelle eingehängt.
Diese Schnittstelle ist immer eine C-Schnittstelle. C++ dekoriert Funktionsnamen mit Typinformation, damit Überladung möglich ist, und ein C-Aufrufer findet diese Namen nicht. Ein mit extern C ausgezeichneter Block schaltet die Dekoration ab und macht die Funktion für beide Seiten auffindbar. Zwei Dinge dürfen über diese Grenze nicht hinweg: eine Ausnahme, weil der C-Aufrufer sie nicht behandeln kann und das Programm sonst abbricht, und ein Objekt mit nicht trivialem Aufbau, weil die Freigabe auf der anderen Seite niemand auslöst. Beides fängt eine schmale Hülle ab, die Ausnahmen in Fehlercodes übersetzt und rohe Zeiger als undurchsichtige Handles herausgibt.
Gemeinsame Header brauchen einen Präprozessorschutz, der prüft, ob gerade ein C++-Compiler übersetzt, und den extern-C-Block nur dann öffnet. Was der gemischte Betrieb an Aufwand kostet, ist überschaubar, aber real: zwei Compilerkonfigurationen, gegebenenfalls zwei Regelwerke, eine Schnittstelle, die jemand pflegt, und die Disziplin, sie nicht schleichend wachsen zu lassen. Wer diese Grenze bewusst schmal hält, kann später Module einzeln austauschen, ohne das ganze Gerät anzufassen.
Dazu passende Kurse
Wer die Unterschiede nicht nachlesen, sondern an derselben Aufgabe sehen will, findet dafür die Grundkurse zu C und zu C++ nebeneinander im Katalog.
Falls die Entscheidung am Ende gar nicht zwischen diesen beiden Sprachen fällt, hilft der Überblick über alle Programmierkurse beim nächsten Schritt weiter.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Ist C++ auf einem Mikrocontroller langsamer oder größer als C?
Können wir C++ einsetzen, wenn der Hersteller nur einen C-Compiler pflegt?
Was ist von Embedded C++ übrig?
Sollten wir statt dieser Frage nicht gleich auf eine speichersichere Sprache wechseln?
Müssen wir MISRA einhalten, wenn wir gar nicht sicherheitsgerichtet entwickeln?
Passt thematisch dazu
Wer die Frage nach der Speichersicherheit ernsthaft stellt, landet schnell bei Rust, und dann geht es weniger um die Sprache als darum, wann sich der Wechsel für ein eingespieltes C++-Team rechnet .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Sprachfrage an eigenem Code entscheiden
Bei cmt siehst du beide Sprachen an derselben Aufgabe: was der Compiler in C++ abfängt, was in C das Review leisten muss und wo die Grenze zwischen beiden im eigenen Projekt sinnvoll verläuft.