Höllische Programmiersprachen Seminar im Wintersemester 2015 Multistage Programming via Präprozessor

Transkript

1 Höllische Programmiersprachen Seminar im Wintersemester 2015 Multistage Programming via Präprozessor Dániel Somogyi Technische Universität München 18. Dezember 2014 I

2 Inhaltsverzeichnis 1 Einführung 1 2 Multi-Stage Programming Basiskonstrukte ein Beispiel zur veranschaulichung Präprozessor Funktionsweise Möglichkeiten die #define und #undef Direktiven Die #include Direktive Bedingte Compelierung Die Operatoren Weitere Direktiven Einsatzgebiete Vor- und Nachteile eines Präprozessors Vorteile Nachteile Evaluation 11 II

3 Zusammenfassung Viele der verbreiteten Programmiersprachen wie etwa Java erlauben es dem Nutzer mit einer Folge von Befehlen ein Programm zu schreiben und so bestimmte Aufgaben zu erledigen. Jedoch ist diese Befehlsfolge, oder Code, fest vorgegeben. Es wird an den Compiler zum übersetzen gegeben und heraus kommt eine ausführbare Datei. Durch Metaprogrammierung lässt sich dieser geschriebene Code durch das Programm selbst manipulieren. Eine Art der Metaprogrammierung nennt sich Multi-Stage Programming. Hierbei besteht die Compelierung des Programmes aus mehreren stufen, bei denen jeweils nur bestimmte Befehle betrachtet und umgesetzt werden. Der Präprozessor, unter Anderem in C genutzt, zeigt eine Form des Multi-Stage Programming. Dieser prüft den Code nach bestimmten Befehlen, manipuliert es entsprechend und übergibt diese geänderte Fassung der Datei an den Compiler. Der wiederum erstellt daraus eine ausführbare Datei. Diese Ausarbeitung zeigt die Vorteile von Multi-Stage Programming mit dem C-Präprozessor, wie bessere Übersichtlichkeit und Effizienz, weist aber auch auf die Gefahren hin, welche das Programm schnell ins negative ziehen. III

4 1 Einführung Neben vielen Programmiersprachen, wie zum Beispiel C, Haskell oder Java, gibt es auch eine Reihe von Programmieransätzen oder -techniken. Diese sind unter Anderem die Funktionale Programmierung und die Objektorientierte Programmierung. Eine weitere, besondere Form ist die Metaprogrammierung. Das Besondere an diesen Programmiersprachen ist, dass sie selbst Programme oder Programmteile analysieren, Erzeugen und bearbeiten können. Eine unterklasse der Metaprogrammierung ist die Multi-Stage Programmierung. Zusätzlich zum normalen übersetzen in eine ausführbare Datei durch den Compiler wird multi-staged Code ein-, oder auch mehrfach, durchlaufen. Hierbei werden bestimmte Befehle bereits ausgewertet und der Code wird teilweise sogar abgeändert. Erst dieser neue, veränderte Code wird tatsächlich vom Compiler in ein tatsächliches, lauffähiges Programm übersetzt. Oft braucht man für diese Besondere Programmierung zusätzliche Erweiterungen (zum Beispiel Mint für Java). Einige Programmiersprachen besitzen jedoch von Haus aus Möglichkeiten, um den Code sich selbst manipulieren zu lassen. Diese Sprachen besitzen hierfür einen sogenannten Präprozessor, welcher vor dem Compiler den Code nach bestimmten Befehlen durchsucht und ihn dementsprechend abändert. Richtig gehandhabt kann man damit große Vorteile, besonders in der Performance gewinnen, jedoch birgen multi-stage Programme und Präprozessoren viele Gefahren und Probleme, weshalb man sie nur mit Vorsicht genießen sollte. 2 Multi-Stage Programming Multi-Stage Programmierung basiert auf eine einfache Idee: Wir schreiben ein Programm in einer beliebigen Programmiersprachen, fügen jedoch einige Befehle hinzu, mit denen wir bestimmte Teile des Programmes bereits zur Compelierzeit auswerten lassen können. Somit muss zur Laufzeit selbst dieser Teil nicht mehr berechnet werden und wir gewinnen Ressourcen, sowohl Zeit, als auch Speicher. Hierfür brauchen wir eine Möglichkeit um vor der eigentlichen Compelierung neuen Code zu generieren. Wichtig ist hierbei, dass schon während der Compelierung sowohl auf die korrekte Syntax, als auch auf Codesicherheit geachtet wird um nicht erst zur Laufzeit entsprechende Fehler zu bekommen. 2.1 Basiskonstrukte Für die MSP gibt es Prinzipiell nur drei Basiskonstrukte, Brackets (oder Klammern), Escape und Run. Mit den Klammern.<>. kann man Ausdrücke umgeben und sie damit verzögern. Dies bedeutet, dass sie als Code-abschnitt betrachtet werden. Dadurch wird nicht mehr zur Laufzeit der Ausdruck ausgewertet und weitergegeben, sondern noch durch die erste Stage des Compelierens der Code an die passende Stelle eingesetzt. Dadurch hat man auch nicht mehr den vorherigen 1

5 Datentyp (z.b. Integer), sondern Code vom Datentyp (also z.b. Code vom Typ Integer). Das Escape. Dient zur konkatenation von mehreren Verzögerten Ausdrücken. Dadurch kann man aus mehreren kleinen Code Abschnitten in Klammern ein größeres bilden, was besonders bei Funktionsaufrufen genutzt wird. Die Code-abschnitte werden letzendlich mit einem Run.! tatsächlich compeliert und ausgeführt. 2.2 ein Beispiel zur veranschaulichung Um das Prinzip und die Funktionsweise eines multi-stage Programmes zu erklären folgt ein einfaches Beispiel. Wir nehmen an, wir haben in einer singlestaged Programmiersprache die Funktion power (n,x) = (n == 0)? 1 : x * power ((n-1), x); welche uns die Potenz mit der Basis x für den (nicht negativen) Exponenten n berechnen soll. Da wir häufig die Quadratische Funktion brauchen schreiben wir eine zusätzliche Funktion square(x) = power (2,x); Man erkennt schnell, dass wir so einen großen Overhead erhalten, da durch die Rekursion die erste Funktion power(n,x) drei mal aufgerufen wird. Schneller wäre es, wenn wir die Quadratfunktion einfach als square(x) = x*x schreiben würden, jedoch ist dann power(n,x) aus dieser Sicht nutzlos. Wollten wir außerdem noch andere Exponenten standartisieren wäre es ein zu hoher Aufwand jede Funktion per Hand schreiben zu müssen. Mithilfe von Multi-stage Programmierung können wir unsere Ausgangsfunktion erweitern. Wir schreiben power(n,x) = (n == 0)?.<1>. :.<.~ x *.~ power((n-1),x) >.; und square(x) =.!.<power(2,.<x>.)>.; Wichtig ist in diesem Fall, dass wir nicht mehr mit Integern, sondern (durch die Klammerung) mit Code vom Typ Integer Arbeiten. Deshalb musste auch die 1 in power(n,x) und das x in square(x) geklammert werden. Außerdem ist die Konkatenation von x und dem Aufruf power((n-1), x) mithilfe eines Escape-Zeichens zu beachten. In der Funktion square(x) wird schließlich alles wieder Ausgewertet, indem wir den Run-Befehl davor setzen. 2

6 Noch vor der Compelierung wird die Funktion auf einer höheren Stufe ausgewertet, was schließlich zu square(x) =.!.<.~x*.~.<.~x*.~.<1>.>.>.; führt. Zusammengefasst ist dass nur noch square(x) =.!.<x*x*1>.; und nach dem ausführen von run ergibt es square(x) = 1*x*x; An den Compiler selbst wird nur dieser letzte Ausdruck weitergegeben. Staging hat dafür gesorgt, dass der Laufzeit-Overhead der Quadratfunktion nicht mehr vorhanden ist, sondern zur Compile-zeit eliminiert wurde[9]. Hier möchte ich Anmerken, dies ist nur ein einfaches Beispiel, formuliert in Pseudocode, ledeglich um das Grundprinzip zu verdeutlichen. In Multi-Staged Programmiersprachen gibt es viel mehr zu Beachten, unter Anderem muss der Zugriff von innerhalb der Klammern auf Variablen außerhalb verhindert werden. Noch mehr auf die Multi-staged Programmiersprachen einzugehen würde den Rahmen sprengen. Wen die multi-stage Programming besonders interessiert sollte sich die Arbeit A Gentle Introduction to Multi-stage Programming ([9]) durchlesen, wir fahren mit einer genaueren Form fort, nämlich den Präprozessoren. 3 Präprozessor Eine besondere Form von Multistage Programming bieten die sogenannten Präprozessoren (PP). Diese sind standardmäßig in den Compiler einer Sprache integriert und bieten eine reihe von Befehlen, um den Code selbst zu bearbeiten und bestimmte Befehle schon während der Compelierung auszuführen. Einen Präprozessor bietet unter Anderem die Sprache C 1, sowie deren fortführungen, wie C++ oder C#. Dieser wird hier auch genauer beschrieben, konkret im Bezug auf den GNU C preprocessor, welcher im GNU C-Compiler enthalten ist. 3.1 Funktionsweise Der CPP wird beim Compelieren automatisch aufgerufen. Hierbei wird der Code über mehrere Schritte verändert, bevor der Compiler sich ans Werk macht. Vor allem anderen wird der Zeichensatz angepasst. Der Code darf in einem Beliebigen Zeichensatz geschrieben werden (meißt ASCII), die C-Quelldaten 1 seit [8] 3

7 müssen jedoch dem Unicode-Standard 2 entsprechen. Nachdem der PP seine Arbeit beendet hat werden char-konstanten und Strings in den Zeichensatz der Ausführung zurückkonvertiert, um eine korrekte Ausgabe zu garantieren. Als nächstes wird der Code aufbearbeitet. Nachdem die Datei in den Speicher geladen wurde, wird es in einzelne Zeilen getrennt. Welche Zeichen tatsächlich als Zeilenumbruch akzeptiert werden ist Compilerabhängig, die gängigen jedoch machen keinen Unterschied zwischen den dafür typischen ASCII Kontrollzeichen 3. Hierbei werden auch Zeilen, welche in der Datei über mehrere Zeilen geschrieben wurden (mit \ ), in eine vereinigt. Kommentare (/*.. */ bzw. //..) werden durch einzelne Leerzeichen ersetzt, da sie der Compiler nicht beachten soll. Auch die sogenannten Trigraphen werden ersetzt. Trigraphen sind dreistellige Zeichenkombinationen, die andere Sonderzeichen ersetzen sollten, falls die gewünschten Zeichen auf der Maschine oder dem Zeichensatz nicht verfügbar sind. Heutzutage sind diese jedoch kaum bis gar nicht mehr in Gebrauch [2]. Sind die Textformatierungen fertig, wird der Code in preprocessing tokens unterteilt (Tokenisiert). Der C-Compiler erledigt diese Arbeit danach nicht mehr, jeder Token aus dem Präprozessor wird zu einem Token im Compiler. Der Tokenizer ist allerdings nicht sehr intelligent. So sind identifier (Variablennamen) zwar (wie in C selbst) definiert als beliebige Zeichenfolge aus Zahlen, Buchstaben und Unterstrichen, beginnend mit Unterstrich oder Buchstabe, jedoch sind die C-Schlüsselwörter nicht ausgeschlossen. Dies und andere vergleichbare Unterschiede können leicht zu Fehlern im Code führen. Solche Probleme werden unter genauer erklärt. Erst danach werden Anpassungen getroffen, welche durch den Programmierer selbst beeinflussbar sind. Mit der sogenannten preprocessing language (Präprozessorsprache) kann man dem PP Befehle erteilen bestimmte Codeabschnitte zu ersetzen und zu Manipulieren. Bis auf wenige vordefinierte Makros werden diese in preprocessing directives (Präprozessor-Direktiven) definiert. Das sind Codezeilen, welche (bis auf whitespace-charaktere vor und nach dem # ) mit einem #name beginnen, wobei name die Direktive bestimmt, gefolgt von eventuellen Parametern und dem Befehlssatz. Wie diese direktiven auszusehen haben, und welche Möglichkeiten es gibt steht im folgenden Kapitel [3, 6]. 3.2 Möglichkeiten Mit bestimmten Befehlen, den Präprozessor-Direktiven, kann man den Quelltext aktiv verändern. Die Anzahl der Präprozessor-Direktiven hält sich in Grenzen. Die wichtigsten sind #define, #undef, #include, #if, #ifdef #elif, #else und #endif. Alle Befehle haben strikte Vorgaben, wie sie genutzt werden können und wie sie den Code beeinflussen. Neben den Direktiven gibt es drei Operatoren, die in allen Befehlen genutzt werden können. Dies sind das Backslash ( \ ), das Doppelkreuz( # ) und das 2 ISO LF - Zeichenvorschub, CR - Wagenrücklauf, sowie deren Kombination [1] 4

8 Doppelte Doppelkreuz ( ## ). Alle anderen Operatoren (wie +, oder - ) werden vom Präprozessor selbst nicht ausgwertet, sondern nur eingesetzt. Im folgenden sind alle Direktiven sowie die Operatoren und deren Funktionen kurz erklärt die #define und #undef Direktiven Bei der Direktive #define kann man zwischen zwei arten Unterscheiden. Einerseits kann man symbolische Konstanten, als auch komplexere Makros erzeugen. Die Syntax ist mit #define NAME(p1,p2,..) MAKRO_BODY denkbar einfach. Hierbei steht NAME für den Bezeichner und p1,p2,.. für beliebig viele Parameter des Makros. Auch die Funktion lässt sich in einem Satz erklären: Im folgenden Code wird NAME(a1,a2,..) (a1,a2,.. stehen für Argumente) durch MACRO BODY ersetzt und die Argumente werden entsprechend eingesetzt. Wichtig ist, dass zwischen dem Namen und den Parametern kein Leerzeichen oder andere Whitespace-Zeichen stehen dürfen. Die Definition ist erst ab dem Punkt gültig, wo sie gesetzt wird, nicht rückläufig. Makros dürfen zwar andere Makros nutzen, jedoch ist Rekursion direkt nicht möglich. Der Präprozessor ersetzt nur Textinhalte und führt diese nicht aus. Rekursion würde so zu einem endlosen Einsetzen Führen. Damit dies nicht passiert wird nur einmal ersetzt. Stand der Makroname selbst im Makro steht dieser nun auch im Code. Um einen Compiler-Fehler zu vermeiden muss eine Funktion mit dem gleichen Namen exestieren. Ohne Parameter hat man einfache Konstanten. So kann man mit #define PI 3.14 die Konstante PI erzeugen und ab da überall im Programm (beziehungsweise im Dokument) nutzen. Für den Compiler erscheint es so, als wäre die Zahl 3.14 überall fest im Code geschrieben und nicht als Variable. Mit Parametern definiert man kleine Funktionen. Die Anweisung #define POW(x) (x) * (x) erzeugt ein kleines Makro für die Berechnung des Quadrates von x. Der Präprozessor ersetzt dann die Codezeile y = POW(3) durch y = (3) * (3) 5

9 und gibt dann diesen Code dem Compiler weiter. Es ist bei Makros besonders auf die Klammerung zu achten, denn der Präprozessor achtet nicht auf etwaige mathematischen Regeln wie Punkt vor Strich, sondern ersetzt die Textpassagen einfach, was leicht Fehlern führt. #undef ist das Gegenstück zu #define. Um ein Makro neu zu definieren muss die definition erst entfernt werden. Mit dem Befehl #undef NAME wird der mit #define NAME Definierte Makro oder Konstante wieder gelöscht. Versucht man danach diese zu nutzen erhält man einen Compilerfehler. Ähnlich wie Bibliotheksklassen mit vordefinierten Funktionen exestieren auch vordefinierte Makros. Viele Compiler bieten eigene an, nach ANSI sind jedcoh nur sechs Makros vordefiniert. Diese dienen eher der Überwachung des Programmes [4, 5, 6]. DATE wird durch einen String ersetzt, welcher dem Compelierungsdatum entspricht. TIME zeigt die letzte Compelierungszeit an. FILE wird ebenfalls zu einem String, dem aktuellen Dateinamen (sie Zeigt jedoch nicht das Verzeichnis). LINE setzt die aktuelle Zeile ein. STDC wird genutzt, um zu prüfen ob der Compiler dem ANSI-Standard entspricht. Wenn ja ist das eine Konstante 1, ansonsten ist sie nicht definiert. TIMESTAMP gibt einen String zurück, welcher den Letzten änderungszeitpunkt der Quelldatei anzeigt (Datum und Uhrzeit) Die #include Direktive Ein sehr häufig genutzter Befehl des Präprozessors ist #include. Damit lassen sich andere Quelldateien in das Programm einbinden, so dass man deren Funktionen ebenfalls nutzen kann. Genau genommen werden nur die sogenannten Header-Dateien eingebunden, was der konkrete Unterschied ist wird hier nicht weiter erklärt. Die #include Direktive hat als Parameter den Dateinamen des jeweiligen Headers, es gibt aber zwei verschiedene Formen. Entweder, der Name steht in 6

10 spitzen Klammern (#include <file.h>), das bedeutet, die Datei ist in einem Standardverzeichnis (meißt für die Standardbibliotheken). Oder der Dateiname steht in Anführungszeichen (#include "file.h"), wodurch die Datei im aktuellen Verzeichnis gesucht wird. Beide Ordner lassen sich für gewöhnlich mit dem Compileraufruf spezifizieren Bedingte Compelierung Die restlichen Direktiven gehören zusammen und dienen der bedingten Compelierung (Conditional Compilation). Ähnlich, wie im normalen C-Code kann man mit #if Bedingungen abfragen und dementsprechend Codeabschnitte entfernen lassen. Die Struktur ist Vergleichbar mit der normalen if-anweisung von C: #if BED_1 anweisung1; #elif BED_2 anweisung2;... #else anweisung_else; #endif Das ganze wird mit einem #if, gefolgt von einer Bedingung BED 1, eingeleitet. Ab der nächsten Zeile folgt ein Anweisungsblock anweisung1;, in dem sowohl normaler C-Code, als auch weitere Makro-definitionen stehen können. Ist das Ergebnis der Bedingung BED 1 == true, also nicht-null, wird der entsprechende Anweisungsblock anweisung1; einfach im Code gelassen, die anderen Anweisungsblöcke verschwinden. Gilt BED 1 == false, verschwindet der Block aus dem Code und die nächste wird geprüft Bedingung. Diese muss nach einem #elif stehen. Das Ganze kann beliebig oft wiederholt werden. Als letztes kann man mit einem #else ein Standardanweisungsblock definieren. Dieser bleibt bestehen, wenn alle anderen Bedingungen 0 ergeben haben. Anschließend muss mit #endif der Befehl abgeschlossen werden. Die #elif und #else-anweisungen sind Optional, das #endif muss bei jeder Bedingten Compelierung dabei stehen. Für die Bedingungen in der #if-direktive gibt es noch besondere Voraussetzungen. Die Bedingung muss eine Konstante ergeben, jedoch sind hier die normalen Arithmetischen Operatoren, sowie weitere Makro-Anweisungen erlaubt. Diese Makros werden noch vor der Auswertung ersetzt, damit ist auch Verschachtelung möglich. Nach ANSI-Standard werden diese Bedingungen als long int variablen gehandhabt. Sollte ein Makroname auftreten, welcher (noch) nicht definiert wurde wird einfach eine 0 eingesetzt. Möchte man prüfen, ob ein Makro definiert ist, kann man zwar #if benutzen, jedoch ist es nicht möglich zu unterscheiden, ob das Makro 0 als Ergebnis liefert oder einfach nicht exestiert. #ifdef ist die Direktive dieses Problem zu umgehen. Sie nimmt als Bedingung einen Makronamen und wertet sie zu einer 1 aus, falls 7

11 das Makro definiert wurde, und zu einer 0, falls nicht [5, 6] Die Operatoren Das erste Zeichen ist das Backslash ( \ ) und dient der Verknüpfung von Zeilen. Präprozessor-Direktiven enden nicht mit einem Semikolon, sondern mit einem Zeilenumbruch. Dadurch dürfen sie prinzipiell nur über eine Zeile gehen, mit einem Backslash am Zeilenende wird dem Präprozessor befohlen die aktuelle und die folgende Zeilen zu einer längeren zu verbinden. Dies kann beliebig oft wiederholt werden, ist jedoch keine sehr übersichtliche Art. Das zweite Zeichen ist das Doppelkreuz ( # ). Dieses zeichen umschließt einen darauf Folgenden Ausdruck mit Anführungszeichen. Schreibt man folgenden Code: #define str(s) #s... printf( str(hello World!) ); so übersetzt es der Präprozessor in printf( "Hello World!" ); Schließlich gibt es noch das Doppelte Doppelkreuz ( ## ), auch Verkettungsoperator genannt. Dieser Operator verkettet zwei Token. Damit kann man zum Beispiel beim Funktionsaufruf zwischen mehreren Funktionen mithilfe von Variablen frei wählen. Veranschaulichen kann man das folgendem dem Codeausschnitt #define callfunc(x) funk ## x... t = callfunc(3)(); Hierbei bekommt der Compiler die Zeile t = funk3(); übergeben. Anstelle der 3 könnte man nun auch andere Zeichenfolgen einsetzen und damit zwischen mehreren Funktionen variieren [5, 6] Weitere Direktiven Es gibt noch weitere, weniger genutzte Direktiven. Zur aktiven Fehlerausgabe während des preprocessing kann man #error benutzen. Dieser Befehl, gefolgt von einem String-Parameter gibt die Meldung auf der Standardausgabe (meistens die Konsole) aus und unterbricht die Compelierung. Da man jedoch nur 8

12 mit der #if und der #ifdef direktive Bedingungen abfragen kann geschieht das selten. Um sich die Zeilenausgaben von LINE und FILE angenehmer zu machen kann man mit #line die aktuelle Codezeile und Datei definieren. Die Direktive nimmt eine oder zwei Parameter, entweder eine Zahl als Zeile, oder eine Zahl und einen String als Zeile und Dateinamen. Einige Compiler bieten sogenannte pragma-direktiven an. Mit dem Aufruf #pragma kann man den Compiler selbst manipulieren. Diese Aufrufe sind jedoch meist Compilerspezifisch und werden daher hier nicht behandelt [3]. 3.3 Einsatzgebiete Der C-Präprozessor bietet viele möglichkeiten, den Code zu beeinflussen, da stellt sich schnell die Frage: Was macht man damit? Eine der Offensichtlicheren Einsatzgebiete ist die einfache und übersichtliche Nutzung von Konstanten und k urzen Funktionen. Diese lassen sich als Makro definieren und mit einem aussagekräftigen Namen überall verwenden. Hält man sich an die Konvention der Großbuchstaben in Makronamen kann man auch gut im Code sehen, was nur Makros und was wirklich Funktionen sind. Ebenfalls leicht zu erraten ist der Einsatz des Befehls #include. Jeder, der schon einmal in C Programmiert hat nutzt dieses Makro, wenigstens für die Einbindung von Standardbibliotheken. Bei Größeren Projekten wird es jedoch unerlässlich den Code in mehrere Teile und damit Dateien zu unterteilen, allein schon für die Mehrfachnutzung von Funktionen. Bei Dateien mit zu vielen LOC hat man keine Übersicht mehr und keiner versteht, was wie gemacht wurde. Am häufigsten wird der Präprozessor, besonders die bedingte Compelierung, für das Debugging eingesetzt. Mithilfe von Makros kann man sehr gute Fehlerausgaben erstellen, die mit beinhaltender Datei und Zeile leicht zum Fehler führen. Dazu definiert man sich oft ein konstantes Makro, zum Beispiel DEBUG, sodass man mit Bedingter Compelierung zusätzliche Ausgaben erhält und das Programm während der Laufzeit prüfen kann. Ist das Debuggen fertig negiert man die Konstante mit #undef DEBUG und man hat keine zusätzlichen Texte mehr auf der Konsole. Besonders praktisch an dieser Form von Debugging ist, dass man es sehr einfach wieder herstellen kann. Möchte man später am Code weiterarbeiten, und beim Testen und Debuggen die ursprünglichen Ausgaben wieder haben, muss man ledeglich den #undef Befehl wieder löschen[5, 6]. 3.4 Vor- und Nachteile eines Präprozessors Nachdem man gelernt hat, was der Präprozessor alles kann, fragt man sich natürlich, wann man ihn einsetzen sollte? Die meißten Makros lassen sich auch 9

13 als Funktion schreiben und umgekehrt, was ist besser? Wieso nutzt man Bedingte Compelierung zum Debuggen? Die meißten dieser Fragen lassen sich durch das Aufzeigen von Vor- und Nachteilen leicht beantworten Vorteile Einige der Vorteile des Präprozessors erschließen sich aus den Einsatzgebieten. So kann man dank symbolische Konstanten, definiert durch Makros sauberen und leicht leserlichen Code schreiben, und mithilfe von bedingter Compelierung sehr angenehmen Debuggen. Für andere Vorteile muss man jedoch genauer beobachten. Oft wird, wenn man Makros kennenlernt, die Frage gestellt: Warum Makros? Oder warum Funktionen? Was ist der Unterschied? Am wichtigsten ist wohl die Geschwindigkeit. Makros sind grundsätzlich schneller als Funktionen. Das liegt daran, dass ein Funktionsaufruf zusätzlichen Overhead benötigt, unter Anderem um die Programmausführung an den Funktionscode, und am ende wieder zum Hauptprogramm zu übergeben. Bei einem Makro gibt es diesen Overhead nicht, da der Makro-Körper ja direkt an die entsprechende Stelle kopiert wurde. Dieser unterschied ist zwar sehr gering, aber besonders bei kurzen Funktionen kann das Verhältnis zwischen dem zusätzlichen Overhead und der eigentlichen Funktionsausführung relativ groß werden. Auch kann als Vorteil gesehen werden, dass Makros nicht Datentypspezifisch sind. Dadurch kann man das Selbe Makro für mehrere Datentypen benutzen, ohne die Eingabewerte vorher zu casten oder mehrere Funktionen schreiben zu müssen. Mit #define MIN(a,b) ((a) < (b)? (a) : (b)) kann man sich ein Makro definieren, welches das kleinere von zwei Zahlen zurückgibt, wobei egal ist, ob a und b ganze Zahlen, oder Dezimalzahlen sind[5, 6] Nachteile Zwar hat der Präprozessor schöne seiten, jedoch raten die meißten C-Lehrbücher zu großer Vorsicht, wenn man Makros oder andere Präprozessor-Direktiven einsetzt. Neben offensichtlichen Problemen, wie dem leichten Verlust von Übersichtlichkeit, zum Beispiel durch mehrzeilige Makros, oder zu viel bedingter Compelierung, kann es auch unscheinbare Probleme mit sich führen den Präprozessor zu nutzen. Es ist sehr leicht kleine Fehler in den Code zu bekommen, welche in C alleine gar nicht möglich sind. Wie schon in erwähnt achten Makros nicht auf die Klammerung, und ersetzen den aktuellen Code einfach. Wenn man ein Makro mit einem Arithmetischen Ausdruck aufruft, so wird nicht, wie bei Funktionen, erst der Parameter berechnet, sondern der ganze Arithmetische Ausdruck eingesetzt. Das verursacht leicht Rechenfehler, falls die Makros nicht genügend ausgeklammert sind. 10

14 Makors erlauben zudem kein Leerzeichen zwischen dem namen und den Klammern für die Argumente. Steht dennoch eins da, so wird die Klammer, und damit auch die Parameterliste, als Teil des Makro-Körpers angeshen und mit in den Code eingesetzt. Definiert man sich also das Makro #define addfive (a) (a) + 5 und benutzt es mit y = addfive(x); so expandiert das zu y = (a) (a) + 5 (x); was offensichtlich nicht gewünscht war. Hat man Glück, erkennt der Compiler den Fehler durch die falsche Notation. Hat man jedoch Pech können so auch vollkommen legale Ausdrücke entstehen, die einfach während der Laufzeit Probleme machen. Auch kommen oft Fehler zustande, wenn aus Macht der Gewohnheit Makros mit einem Semikolon abschließt. Das Semikolon wird in diesem fall ebenfalls zum Makrokörper gezählt und einfach mit eingesetzt. Letzendlich ist auch darauf hinzuweisen, dass Fehler, welche durch den Präprozessor zustande kommen, meist nur sehr schwer gefunden werden, was die Fehlersuche zu einer Qual werden lässt[5]. Auch die Performance kann unter Makros leiden. Zwar sind Funktionsaufrufe langsamer als Makros, aber Funktionen stehen dafür nur einmal im Code. Makros werden an jeder einzelnen stelle, wo sie aufgerufen werden, expandiert. Nutzt man ein Mehrzeiliges Makro nun in hunderten von Zeilen, so wird der Code beim Compelieren erstmal um ein paar Hundert zeilen länger. Bei kleinen Programmen ist das kein Problem, ähnlich wie es keinen wirklichen Geschwindigkeitsvorteil bringt Makros zu nutzen, aber bei großen Projekten, besonders bei zeitkritischen Aufgaben, muss fein abgewogen werden, ob nun Makros oder Funktionen die bessere Wahl sind [6]. 4 Evaluation Zwar mag multi-stage Programmierung am Anfang einfach aussehen Da es eine Erweiterung für bestehende Sprachen ist, muss man jedoch Permanent mit zwei Konzepten gleichzeitig arbeiten: Man muss die eigentliche Sprache effektiv nutzen und trotzdem erkennen, wann es Vorteile bringt schon vor der Compelierung bestimmte teile des Codes zu berechnen. Die Tatsache dass es nur bedingt Aktivität (zum Beispiel in Foren) um die Multi-Stage Programmierung gibt, und in vielen Arbeiten und Vorträgen (siehe [9, 7]) die selben Beispiele gezeigt werden, weist auch auf wenig Beliebtheit des Konzeptes hin. 11

15 Der Präprozessor mag zwar unerlässliche, auch gute Konzepte bieten (besonders die #include-direktive), jedoch sind einige auch nicht wirklich nötig. Der Effizienzunterschied zwischen Makros und Funktionen ist minimal und besonders auf heutigen Systemen meist vernachlässigbar. Zum Debuggen gibt es eigene Programme, die viel mehr bieten, als einfach nur bedingte Zeilenausgaben, wie zum Beispiel schrittweises abarbeiten eines Programmes oder Echtzeitauswertung von Variablen. Dagegen gibt es jedoch viele Nachteile. Der Präprozessor ist sehr penibel, wodurch sich sehr schnell Fehler einschleichen welche man danach nur schwer findet. Diese und andere Gründe führen dazu, dass sowohl Lehrbücher [6, 5], als auch Foren dazu raten, tatsächlich in C zu Programmieren und den Präprozessor nur mit bedacht zu genießen. Schlussendlich muss ich sagen, dass mich die Multi-Stage Programmierung und der Präprozessor nicht überzeugen konnten, da es einfach zu viele Nachteile und Probleme durch Kleinigkeiten geben kann. Das, und das Konzept von zwei Sprachen paralell sind zu viele Nachteile für den kleinen Gewinn. 12

16 Literatur [1] Ascii codes. [2] Trigraphen. [3] Free Software Foundation. The c preprocessor, [4] Microsoft. Predefined macros. [5] Philip E. Margolis Peter A. Darnell. C - A Software Engeneering Approach. Springer-Verlag, [6] Bradley L. Jones Peter Aitken. C in 21 Tagen. Markt+Technik Verlag, [7] Mathias Ricken. Mint: A multi-stage extension of java. video by RICE University, Houston, Texas. [8] Dennis M. Ritchie. The development of the c language, [9] Walid Taha. A gentle introduction to multi-stage programming. taha/publications/journal/dspg04a.pdf. 13