C vs C++

Die wahrscheinlich “seltsamste” Entscheidung im GATE Projekt ist die duale C/C++ Strategie, wo alles in C implementiert wird und C++ nur noch einen dünnen Layer darüber legt. Die STL soll selten bis gar nicht zum Einsatz kommen.

Warum ist das so?

Weder C noch C++ haben ein formales stabiles ABI auf allen Plattformen. Doch bei C haben sich de-facto Standards so etabliert, dass man bereits behaupten kann, dass es ein C ABI auf allen Plattformen gibt.
Anders gesagt: Alle anderen Sprachen und Technologien bieten Schnittstellen zu C und alle C Compiler verschiedener Hersteller sind (meist) kompatibel zu einander.

Bei C++ sieht das ganz anders aus. STL, Exceptions, RTTI, Name-mangling und vieles mehr ist stark Compiler-spezifisch.
Ein std::string eines GCC (z.B. MinGW ) kann mit einem MSVC nicht verarbeitet werden. Aber eine Funktion wie strlen() aus einer MinGW Bibliothek kann sofort von MSVC aus aufgerufen werden und umgekehrt.

Noch schlimmer sieht es bei weiteren Sprachen aus. C ist der kleineste gemeinsame Nenner, den fast alle bedienen können (Java, Python, C#, …), bei C++ wird es hingegen schon sehr Compiler- bzw. Bibliothek-abhängig.

Tja, deshalb sollte meiner Meinung nach alles Elementare in C abgebildet sein, damit die Funktionalität in allen Sprachen einsetzbar ist.

Vorteile

  • Es wird ein de-facto ABI etabliert.
  • “Objekte” und deren Layouts sind standardisiert.

Nachteile

  • Dem C++ Optimizer werden einige Optimierungsmöglichkeiten genommen.
  • Features wie Exceptions oder RTTI müssen zwischen C und C++ übersetzt werden.

Im Falle des GATE Projektes überwiegen die Vorteile gegenüber den Nachteilen.

In einem anderen Projekt hatte ich mal den umgekehrten Ansatz verfolgt. C++ war das primäre Framework und dann war eine Übersetzung nach C notwendig. Das war dann aber sehr aufwendig, so dass es nur so selten wie möglich genutzt wurde. Sonderlich praktikabel war das also nicht.

Außerdem gibt es Plattformen, die übliche C++ Features wie Exceptions nicht einsetzen (sollten). z.B. MCUs, Arduino, Treiber.
Hier ist es von Vorteil, dass es ein C-Framework gibt, das alles abdeckt.


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!