C++ für Echtzeit-Anwendungen

					[url=/c-fuer-echtzeit-anwendungen-a-594143/][b]C++ für Echtzeit-Anwendungen[/b][/url]


					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?

					[url=/c-fuer-echtzeit-anwendungen-a-594143/]zum Artikel[/url]

					[url=/c-fuer-echtzeit-anwendungen-a-594143/][b]C++ für Echtzeit-Anwendungen[/b][/url]


					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?

					[url=/c-fuer-echtzeit-anwendungen-a-594143/]zum Artikel[/url]

Ein Vergleich beider Programmiermethoden mittels Assembler ist nicht schlecht, allerdings beschränkt man sich hier auf das Aufrufen von Funktionen. Da werden nur Zeiger addressiert und verzweigt. Die Qualität des kompilierten Programmes hin zu Assembler richtet sich auch nach der zugrunde liegenden Programmiersprache, der Komplexität des Programms und den getroffenen Compiler-Einstellungen. Nicht jeder Compiler wandelt geschickt nach Assembler um und sogenannte Lücken durch pipeline stalls sind auch nicht erkennbar.

hartmut.schorrig

Mich freut, dass der Artikel und die Untersuchungen zeigen, dass es im konkreten Fall keine Zeitunterschiede in den entsprechenden Funktionsaufrufen in C und C++ gibt. Ich denke, man kann das verallgemeinern. Für schnelle Echtzeitverarbeitung sollte man diese Themen (Art der Umsetzung in Maschinencode, welche CompilerOptions, welcher Programmierstil) für die jeweilige Plattform jedenfalls voruntersuchen. Diese Dinge beeinflussen die Rechenzeit mehr als die Programmiersprache an sich.

Programmierstil: Ich verwende seit den 90-gern einen Objektorientierten Stil in C, mit thiz als Instanzenzeiger und meist C++-Compilierung. Auf die C-struct aufgesetzt eine class, weil einiges in C++ einfach schöner zu schreiben ist (überladene Operatoren). Dort, wo es harte Echtzeit gibt (z.B. 50 µs Zyklus mit viel Regelungstechnik) braucht man meist keine Vererbung. Für die parallelläufige Datenauswertung, Parameteroptimierung etc. kann man dann auch die etwas aufwändigeren dynamischen Calls einsetzen (virtuelle Methoden). Diejenigen Routinen, die wiederverwendet werden sollen in anderen Projekten sind halt in C, falls dort nur C eingesetzt werden sollte. Also ein guter Mix aus beiden Programmiersprachen, die eigentlich (fast) abwärtskompatibel sind.

Der Programmierstil aus meiner Erfahrung sollte immer objektorientiert sein, auch in C! Der Kontext (thiz-Zeiger, Instanzendaten) ist ein schnelles Funktionsargument, der Datenzugriff auf referenzierte Daten ist in der Regel NICHT LANGSAMER als der globale Datenzugriff (!) da CPUs meist die zusätzliche Adressrechnung parallelläufig ausführen und oft benutzte Daten (thiz) in Registern halten. thiz als Instanzenzeiger in C deshalb, weil this bei C++-Compilierung nicht dafür geht.

Steht im Artikel: Vorsicht bei Verwendung von Standardlibraries in C++.
Steht auch im Artikel: new und delete nur wenn notwendig und zulässig verwenden, es geht oft auch ohne.

Hinweis: emC-Library (Embedded Mulitplatform C) unter www.vishia.org/emc

hartmut.schorrig

Frage an das Auditorium: Ich kann mich erinnern, in der Vergangenheit das Problem gehabt zu haben, dass bestimmte Daten bestimmten Speicherbereichen eines embedded Prozessors zugeordnet werden sollen. Chipinterner /externer memory, auch insbesondere const in den Flash-Memory. Das ist zu erledigen mit Segmentzuweisungen beim Compilieren und einem Linker Description File, toolabhängig verschieden für die diversen Prozessoren.
Nun ist in C ein

const MyType data = { .... };
const int nr = 234;

direkt in den Flash compilierbar, da die Initializer alle zur Compilezeit berechenbar sein müssen, bei C. In C++ ist die Arbeit mit const erweitert, man kann schreiben:

const int nr = callAnyRoutine();

Diese Routine wird zur Runtime vor main() durchgearbeitet. Das bedeutet aber das das Datenelement nr und adäquat const Instanzen nicht direkt in den const-Speicherbereich (also flash) hineincompiliert werden können. Sie sind damit per se nicht schreibgeschützt.
Falls dies wichtig ist, oder der Prozessor wenig RAM hat, aber viel FROM, sehr viele const-Daten, dann muss man für diese Teile C verwenden !?
Damit ergibt sich aber eine sinnvolle Arbeitsweise: Teile in C compilieren, andere Teile in C++. Das arbeitet gut miteinander , extern C benutzen für C-like Definitionen im C++-compilier-Teil.