|
Gegenanzeigen: Was spricht gegen eine Verwendung von C++ und wie kann man den Schwierigkeiten begegnen?
- Mikrocontroller sind verhältnismäßig langsam und haben einen sehr kleinen Programm- (ATemga32: 32 Kilo-Bytes) und einen noch kleineren Arbeitsspeicher (ATemga32: 2024 Byte).
- Das läuft gegen die OOP, da diese eine noch höhere Abstraktion gegenüber der Maschinensprache darstellt und dadurch die Gefahr besteht, dass der Compiler aus einem C++-Quellcode weniger effizienten Maschinencode generiert, als dies bei einem Assembler-Quellcode, aber auch bei einem C-Quellcode der Fall ist.
- In welchem Maße diese Befürchtungen berechtigt sind, soll im Verlauf der Vorlesung auch experimentell ermittelt werden.
- Es gibt aber bestimmte Maßnahmen, die die Gefahr ineffizienten Codes eindämmen:
|
Kein Allokieren von dynamischem Speicher
- Absolut fatal ist es bei einem Mikrocontrollerprogramm zur Laufzeit Speicher zu allokieren.
- Bei objektorienteirten Programmier-Techniken werden häufig dynamisch Objekte erzeugt und wieder zerstört. - Gerade darauf sollte man von vorn herein verzichten, indem man Objekte nur am Beginn der main-Methode anlegt und sonst nirgends, insbesondere nicht innerhalb von Funktionen.
|
Intensive Nutzung von #define-Statements
- Die Lesbarkeit von Programmen kann man durch die Verwendung sprechender Variablen- und Funktionsnamen erhöhen.
- Jedoch verbrauchen Variablen Speicher und der Aufruf einer Funktion Rechenzeit (merken des aktuellen Programmzustands, Sprung in die Funktion, Ausführen der Funktion, Rücksprung, Wiederherstellung des aktuellen Programmzustands).
- Keinerlei Speicher verbraucht die Verwendung von #define-Statements. Mit ihnen kann man Code lesbarer machen. Zur Erinnerung: VOR dem eigentlichen Kompiliervorgang, führt der Precompiler die in den #define-Statements vordefinierten Ersetzungen durch. "#define MEINPI 3.14" ist wohl gemerkt keine Deklaration und Initialisierung der Variable MEINPI, sondern es wird einfach VOR dem Kompilieren überall, wo MEINPI im Programm steht 3.14 eingefügt.
|
Nutzung von Kommentaren
- Der Anreiz ist groß, alles zu automatisieren und zu kapseln, um sich mit möglichst wenigen komplizierten Einstellungen z.B. beim Starten des AD-Wandlers befassen zu müssen.
- Jedoch läuft dieses Bestreben kontraproduktiv was Speicherbedarf und Bearbeitungsgeschwindigkeit betrifft.
- Es ist eine Ermessensfrage, wann statt eines aufwändigen Konfigurations-Apparats mit Switch-Anweisungen im Konstruktor, einem einfachen Kommentar für den Benutzer vorzuziehen ist.
- Im Vordergrund soll keine Prinzipienreiterei auf den Paradigmen der OOP stehen, sondern die Benutzerfreundlichkeit der entwickelten Programmkomponenten.
|
Nutzung von Vererbung
- Das Erstellen von Klassen verleitet dazu, jede Eventualität zu berücksichtigen und ein großes Bündel an Methoden dafür bereitzustellen.
- Beispielsweise ist es nützliche in einer Klasse RS232 eine Methode zum Senden ganzer Text, oder von Fließkommazahlen zu haben, aber nicht immer werden diese Methoden wirklich im Programm gebraucht.
- Hier bietet es sich an mit Vererbung zu arbeiten und höhere Methoden in abgeleitete Klassen zu packen.
|
|