2004-06-17T13:57:13Z

Martin:

Allgemein Dateien, die im Rahmen der Verarbeitung einer anderen Datei ''eingeschlossen'' (inkludiert) werden.

Bei der Programmierung werden Include-Files häufig eingesetzt, um das wiederholte Hinterlegen ein und derselben Information in mehreren Dateien zu vermeiden (z.B. die Beschreibung häufig verwendeter Datenstrukturen).

Für die bei der Programmierung von Mikrocontrollern oft verwendeten, [[HLL|höheren Programmiersprachen]] [[C]] und [[C-Plusplus|C++]] bietet der [[C-Präprozessor]] entsprechende Möglichkeiten.

Templates (C++)

2004-06-17T13:49:23Z

Martin:

Templates in C++ - mitunter ''Schablonen'' genannt - erlauben die "generische Programmierung".

Bei der Programmierung von Mikrocontrollern in C++ sind Templates deshalb interessant, weil sie zum Zeitpunkt der Kompilierung greifen und damit zu weniger Overhead führen (können) als sehr "universelle" Bibliotheksfuntionen, deren Leistungsumfang von einer konkreten Applikation nur teilweise benutzt wird. Da Templates nur einmalig hinterlegt sind, vermeiden sie die Nachteile der [[Copy&Paste-Programmierung]].

Ähnlich wie parametrisierte [[Makro]]s kann man Templates als Quelltexte verstehen, die '''einmal''' geschrieben und '''häufig''' eingesetzt werden - jeweils mit mehr oder weniger großen Variationen. Insbesondere lassen sich mit Templates
* Datentypen(*1) und
* Compilezeit-Konstanten
parametrisieren, das heißt bis zu einer konkreten Verwendung einer Template (= Instanziierung) offen halten.

Als Beispiel hier eine Template(-Funktion) zum Vertauschen von zwei Ganzzahlen:
<pre>
template<typename T>
void swap(T* xp, T* yp) {
T tmp; tmp = *xp; *xp = *yp; *yp = tmp;
}
</pre>
Die erste Zeile erklärt dabei dem C++-Compiler, dass das nachfolgend verwendete Symbol ''T'' einen beliebigen Typnamen repräsentiert. (Ohne diese Zeile würde man eine Fehlermeldung wegen eines undefinierten Namens erhalten.)

Bei der späteren, tatsächlichen Verwendung dieser Funktion kann man einen konkreten Typ angeben
<pre>
int a, b;
double c, d;
struct s e, f;
...
swap<int>(&a, &b);
swap<double>(&c, &d);
swap<struct s>(&e, &f);
</pre>
oder - noch einfacher - lässt den Compiler aus dem Typ des verwendeten Template-Arguments auf den Typ von ''T'' schließen(*2):
<pre>
swap(&a, &b);
swap(&c, &d);
swap(&e, &f);
</pre>
Beim Programmieren mit Templates sollte allerdings auf die Minimierung von Abschnitten geachtet werden, für die der erzeugte Code '''nicht''' mit den Template-Parametern variiert, zumindest dann, wenn eine Template typischerweise in ein und demselben Quelltext mehrfach mit unterschiedlichen Parametern verwendet wird.
Für das obige Beispiel ist das insofern der Fall, als Zuweisungen in der Template-Funktion Machinencode erzeugen werden, der für die unterschiedlichen Datentypen jeweils verschieden ausfällt. (Z.B. ein ''MOV''-Befehl für 2 oder 4 Byte bei für die Verwendung mit ''int'', 8
Byte für ''double'' und vielleicht einen ''memmove''-Aufruf für die Strukturzuweisung.)

Andererseits könnte der Aufruf von ''swap'' mit den Datentypen ''long'' und ''float'' dazu führen, dass aufgrund der Template zwei Funktionen instanziiert werden, die vom Maschinencode her identisch sind (wenn ''float'' und ''long'' beide 4 Byte haben). Das selbe gilt bei der Verwendung von ''swap'' mit verschiedenen Struktur-Typen der selben Größe.

'''Um den berühmt-berüchtigten "Code-Bloat" durch Templates zu vermeiden, ist also eine gute Kenntnis der Hintergründe des Template-Mechanismus unabdingbar!'''

----
*1: Früher hatten Templates in C++ daher den Namen ''Parametrized Types''.
*2: Voraussetzung dafür ist, dass die Template eine Funktion und keine Klasse beschreibt und dass der parametrisierte Typ ''T'' aus den aktuellen Parametern erkannt werden kann. (Hier: erwartet wird ein ''Zeiger auf T'', übergeben werden mit ''&a'' und ''&b'' konkret ''Zeiger auf int'', also muss es sich bei dem Typ ''T'' in '''diesem''' Aufruf um ''int'' handeln.)

C vs C++

2004-06-17T13:30:22Z

Martin: Link zum ausführlicheren C++-Template-Artikel eingefügt

Speziell bei der Verwendung höherer Programmiersprachen ([[HLL]]s) im Bereich der Programmierung von Mikrocontrollern taucht häufig die Frage auf, ob eine Sprache wie [[C-Plusplus|C++]] für "kleinere" Mikroprozessoren nicht einen zu großen Overhead darstelle und ob man nicht besser bei [[C]] (oder gar [[Assembler]]) bleiben solle.

== Beziehung zwischen C und C++ ==
Ursprünglich entstand C++ als Erweiterung zu C (mit minimalen Ausnahmen - Leitlinie: "As close to C as possible, but no closer"). Damit ist C als Teilmenge in C++ enthalten und jedes C-Programm ist zugleich ein C++-Programm, denn es kann auch mit einem C++-Compiler übersetzt werden (nicht aber umgekehrt!!). Da ein weiterer Grundsatz bei der C++-Entwicklung lautete "You only pay for what you use", entsteht in einem Programm, das ausschließlich C-Features benutzt aber mit einem C++-Compiler übersetzt wird, kein prinzipiell bedingter Overhead.

So weit die Theorie.

== C++ Performance Fußangeln ==
Allerdings waren die Zielsysteme bei der Weiterentwicklung von C++ in den letzten 20 Jahren in der Regel PCs und leistungsfähige Workstations, was in der Praxis zwei wichtige Konsequenzen hatte:
* Die Sprachsyntax von C++ verschleiert mehr als die von C, womit man sich in einem Programm möglicherweise einen hohen, in der Programmierung von Mikrocontrollern unerwünschten Overhead ohne konkreten Nutzen einhandelt.
* Die tatsächlichen Implementierungen von C++ bemühen sich weniger als die von C, ausführbare Programme (Executables) in der sparsamsten, möglichen Form zu erzeugen.

=== Fußangel-Beispiel 1 ===
Mitunter werden beim Einsatz von C++ Programmierrichtlininen angewendet, die im Bereich der Mikrocontrollern-Programmierung unsinnig sind oder zumindest nach anderen Kriterien bewertet werden müssen als im PC- und Workstation-Umfeld.
So führen etwa "vorsorglich angelegte", aber leere Konstruktoren und Destruktoren in der Regel zu vielen Unterprogramm-Sprungbefehlen, an deren Ziel sofort wieder ein Rücksprung steht.

Oder es werden - dem Beispiel von Java oder bestimmten Entwurfsmustern folgend - Objekte in jedem Fall dynamisch angelegt, was das Einbinden komplexer Unterstützungsroutinen für die Speicherverwaltung auslöst und in keinem Fall zu Ergebnissen führt, deren Performance vergleichbar zu einfachen Variablen auf dem Stack oder an festen Adressen ist.

=== Fußangel-Beispiel 2 ===
Manchmal wird ein einfaches "hello, world"-Programm in C und eines in C++ auf einem PC kompiliert und die Größe des erzeugten Executables als Kriterium für den Resourcen-Bedarf der jeweiligen Programmiersprache herangezogen. Dieser Vergleich kann sehr in die Irre führen, da die typischen Ausgabe-Anweisungen der Sprachen C und C++ von Bibliotheksfunkionen abgewickelt werden, die aber mit Sicherheit bei der Kompilierung für einen Mikrocontroller ganz anders aussehen (wenn sie dort überhaupt vorhanden sind).

Bei der Strukturierung von unterstützenden Bibliotheksfunktionen wird im PC- und Workstationbereich kaum darauf geachtet, ob einem Minimal-Programm möglicherweise unnötiger Overhead mit hinzugebunden wird. So könnte beispielsweise - obwohl nur eine einfache Zeichenkette ausgegeben wird - durch eine Ausgabeanweisung die Unterstützung für die Ausgabe aller Datentypen inklusive Gleitpunktzahlen angesprochen werden, dies könnte wiederum das Hinzubinden der mathematischen Bibliothek auslösen und - bei Kompilierung für einen Prozessor ohne Hardware-Support für Gleitpunkt-Operationen - einer weiteren Bibliothek zu deren Emulation. Das alles, wie gesagt, obwohl überhaupt keine Gleitpunktzahl in der konkreten Ausgabe vorkommt.

== Vererbung und Aggregation ==
Beide Mechanismen sind aus Sicht der Umsetzung als geschachtelte Strukturen zu verstehen. Eventuelle kleinere Performance-Einbußen könnten durch die fehlende Möglichkeit der Register-Optimierung entstehen, die ein Compiler bei mehreren, nicht zu einer Struktur zusammengefassten Variablen prinzipiell hat. Allerdings sind die Vor- und Nachteile hier in C und C++ die selben, und insofern ist das Thema für einen Vergleich "C vs C++" nicht relevant.

In größeren Programmen überwiegt in aller Regel der Vorteil der besseren Strukturierung durch die Zusammenfassung von Einzelvariablen, insbesondere wenn auch die in C++ vorhandenen Mechanismen zum Zugriffsschutz eingesetzt werden. In kleinen Programmabschnitten mit extrem kritischer Performance kann ggf. eine "Hand-Optimierung" und Auflösung von Strukturen in Einzelvariablen erfolgen (oder gleich eine Re-Implementierung in Assembler).

== Virtuelle Methoden ==
Virtuelle Methoden sind im Grunde genommen Funktionszeiger und insofern überall dort sinnvoll, wo man in einem C-Programm zur Lösung des Problems einen Funktionszeiger eingesetzt hätte (oder in Assembler eine Einsprung-Adresse in Maschinencode hinterlegt oder übergeben hätte).
Werden Methoden in C++ unnötigerweise "virtual" deklariert (mit anderen Worten: steht die Einsprungadresse immer fest und hätte insofern auch der Compiler oder Linker sie bestimmen können), so ist der Overhead natürlich unnötig - aber auch leicht vermeidbar, indem man solche Methoden eben NICHT als "virtual" deklariert.

Dort, wo sinnvoll, also wo virtuelle Methoden tatsächlich ein PROBLEM lösen helfen, sind sie in der Regel eleganter und programmiertechnisch einfacher zu handhaben als explizite Funktionszeiger.

== Interfaces (Abstrakte Basisklassen) ==
Abstrakte Basisklassen sind im Grunde genommen Bündel von Funktionszeiger und ebenso wie virtuelle Methoden genau dort sinnvoll, wo sie ein Problem lösen helfen. Hierzu ein Beispiel: Ein Embedded-System hat eine Verbindung zu einem Host-Rechner zwecks Datenaustausch. Es besteht entweder ein LAN-Zugang oder an der seriellen Schnittstelle hängt ein Modem. Möglicherweise kommt es im laufenden Betrieb auch zu einer Umkonfiguration oder die Hostverbindung fällt komplett aus, dann sollen die Daten in einem lokalen, nicht-flüchtigen Speicher abgelegt werden.

Damit die Applikation nicht alle Eventualitäten an zahlreichen Stellen des Programms verteilt berücksichtigen muss, abstrahiert man den Datenaustausch z.B.
* Verbindung intiieren
* Daten übergeben
* Übernahme bestätigen
* Verbindung abbauen
in einem Interface. Jede der genannten Operationen entspricht dabei einem Zeiger auf ein entsprechendes Unterprogramms (also dessen Einsprungadresse). Tatsächlich implementiert werden diese Unterprogramm mehrfach (einmal für LAN, einmal für Modem, einmal für lokalen Speicher) und der eigentlichen Applikation wird - mehr oder weniger transparent - einfach das passende Funktionszeigerbündel übergeben, jenachdem, welche Art von Host-Verbindung derzeit möglich ist.

Auch hier ist es wieder so, dass ein Interface - realisiert durch eine abstrakte Basisklasse - im Vergleich zu expliziten Funktionszeigern eleganter und programmiertechnisch einfacher ausfällt (sofern man einmal das Prinzip verstanden hat). Eben so gilt, dass abstrakte Basisklassen zu unnötigem Overhead führen, falls man sie "nur mal so" einsetzt, also ohne dass sie, wie oben dagestellt, ein konkretes Problem lösen.

== Execptions (Ausnahmebehandlung) ==
Mit Exceptions lässt sich ein "alternativer Kontrollfluss" in einem Programm definieren, vorzugsweise zur Handhabung von Fehlersituationen oder anderer "außergewöhnlicher Ereignisse". Mit der Einführung von Exceptions musste in C++ aber auch die Leitlinie "You only pay for what you use" verletzt werden. Das heißt es entsteht stets etwas Overhead, wenn der C++-Compiler Exceptions unterstützt, auch für Programme, die Execptions überhaupt nicht benutzen. Aus diesem Grund lassen sich Execptions über Kommandozeilen-Argumente des Compilers oder in den Projekt-Optionen einer Tool-Chain häufig deaktivieren.

== Laufzeit-Typinformation ==
Laufzeit-Typinformation (auch Runtime Type Information oder RTTI genannt), verursacht unter Umständen ebenfalls einen geringen Overhead in C++, auch wenn ein Programm RTTI nicht benutzt. Insofern gilt wie für Execptions, dass man ggf. nach einer Möglichkeit suchen sollte, RTTI ganz abzuschalten, wenn man das Feature nicht braucht. Auf der anderen Seite ist der RTTI-Overhead im Vergleich zu Exceptions sehr gering und entsteht vor allem im Hinblick auf ein wenig zusätzlich benötigten Speicherplatz, nicht in Form unnötig ausgeführter Anweisungen. (Nach Abschalten der RTTI-Unterstützung darf man also kein "schnelleres" Programme erwarten.)

== Templates (Schablonen) ==
[[Templates (C-Plusplus)|Templates]] sind ein Mechanismus, der zwischen Implementierungs- und Kompilierungs-Zeitpunkt greift. Im Grunde genommen steht mit einer C++-Template "ein bisschen Programmcode" stellvertretend für "möglicherweise sehr viel Programmcode", der aber noch in einem bestimmten Aspekt - einem Datentyp oder eine Konstante - variieren kann. Der allgemeine Teil (Template) wird nur einmalig implementiert und später in mehr oder weniger vielen Varianten kompiliert. (Das am ehesten vergleichbare Äquivalent zu C++-Templates sind in C die Präprozessor-Makros.)

Unter diesem Aspekt betrachtet sind Templates keine Verschwendung (wie manchmal behauptet) sonder sehr sparsam und ideal für Mikrocontroller, da sie im Vergleich zu einer Bibliotheksfunktionen, die quasi "auf Vorrat" viele Varianten berücksichtigen, von denen konkret aber nicht alle genutzt werden, einem Programm nur das hinzufügt, was wirklich benötigt wird.

Auf der anderen Seite sind Templates ein neueres Feature von C++ zu dem bis vor wenigen Jahren auf Seite der Compiler-Lieferanten kaum Erfahrung hinsichtlich der optimalen Umsetzung bestand. Auch in der Fachliteratur werden Templates meist mit viel geringerer Tiefe und weniger Praxisbezug behandelt als diejenigen Features, die schon sehr lange von C++ unterstützt werden (Vererbung usw.). Eine generelle Empfehlung, Templates bei der Verwendung von C++ im Bereich der Mikrocontroller-Programmierung NICHT einzusetzen, ist daraus aber keinesfalls abzuleiten - ganz im Gegenteil: Zur Lösung vieler Probleme sind Templates besser geeignet als etwa Präprozessor-Makros oder gar [[Copy&Paste-Programmierung]].

Benutzer Diskussion:Martin

2004-06-17T13:03:39Z

Martin:

Diskussion:Templates (C++)

2004-06-17T13:02:53Z

Martin:

Um den Artikel klein zu halten, habe ich mich darin auf ein einziges, kurzes Beispiel beschränkt, das nur die Grundlagen der C++-Templates verdeutlichen sollte. Falls Interesse besteht, kann ich aber auch mal ein paar Code-Beispiele mit Templates vorstellen, die ich selbst bei der Programmierung von Mikrocontrollern mit C++ als hilfreich und nützlich empfunden habe. (--[[Benutzer:Martin|Martin]] 15:00, 17. Jun 2004 (CEST))

2004-06-05T15:10:36Z

Martin:

Nachdem ich in den letzten Tagen das Wiki um einige Seiten bereichert habe und in Zukunft vielleicht auch noch ein bisschen mehr von mir kommt, fand ich es etwas netter, wenn künftig ein Name da steht und nicht nur eine IP-Nummer.

Hier mein Kurzsteckbrief:
* Geboren bin ich 1954 in Ludwigshafen am Rhein.
* Kleine Elektrobasteleien haben mich schon sehr früh fasziniert (mit 6 oder 7 Jahren, etwa die Beleuchtung der Puppenstuben meiner Schwestern),
* so etwa mit 10 Jahren kam dann die elektrische Eisenbahn, wo es nicht nur Häuser und Straßen zu beleuchten gab,
* und nach und nach wurde es eben "anspruchsvoller" (Radiobaukasten, Verstärker, Modellschiff mit Funkfernsteuerung und all diese Sachen).
* Bei dieser Gelegenheit einmal schönen Dank an meinen Physiklehrer, der das gefördert hat und mir einige Türen öffnete.
* Eine davon brachte mich frühzeitig mit der Digitaltechnik in Berührung ...
* ... die Gatter und Flipflops waren damals allerdings noch "diskret" mit Dioden und Transistoren aufgebaut.
* "Naturgemäß" folgte ein Studium der Elektrotechnik, nach dem Vordiplom machte ich weiter mit Datentechnik (Technische Informatik).
* Dazwischen gab es immer wieder kleinener Elektronikarbeiten, teils einfach "aus Spaß" dran, teils auch fürs Studium.
* Ein paar Mal landeten meine Sachen auch in Schaltungswettbewerben (Funkschau, Elektronik, so "um Platz 20 herum") oder wurden anderweitig veröffentlicht.
* Dann - Mitte der 1970er - kamen langsam die Mikroprozessoren in Mode ...
* ... für mich als Student war das aber preislich eine Kategorie zu hoch (ein 8080 kostete anfänglich so um die 1000 DM).
* Im Alter von 25 Jahren, noch als Student, meldete ich dann einen "Gewerbebetrieb" an, um im Auftrag Programmierarbeiten erledigen zu können.
* Beruflich bin ich sowohl selbstständig als auch in der Software-Ecke geblieben (meine letzte eigenständige Hardware-Entwicklung war vor knapp 20 Jahren ein Interface zur Ansteuerung eines Lochstreifenstanzers über die Parallel-Schnittstelle).
* Da ich aber schon vor mehr als 20 Jahren auf Unix und C stieß, habe ich von DOS/Windows nicht sonderlich viel mitbekommen ...
* ... einige eher leidvolle Erfahrungen findet man hier: [http://www.rent-a-guru.de/pub/sadstory.html]
* Heute verdiene ich meinen Lebensunterhalt vor allem mit Schulungen, u.a. für die Programmiersprachen [[C]]/[[C-Plusplus|C++]], [[Java]] und [[Tcl/Tk]] und alle [[Unix]]-ähnlichen Betriebssysteme inkl. [[Linux]].
* Derzeit recht gefragte Themen sind "Embedded Linux" und "C++ für Mikrocontroller" - für mich eine willkommene Gelegenheit, wieder "zu meinen Wurzeln" zurück zu finden.
* Interessante Projekte sind natürlich auch willkommen (also wer was hat oder weiß, nur her damit :-))

PS: Wenn ich etwas mehr Zeit habe, scheibe ich vielleicht auch noch etwas mehr und lade auch ein Bild hoch.