Algorithmen & Datenstrukturen Programmieren 1 von Prof. Jürgen Plate

9 Programmierstil, Fallstricke, Module

9.1 Programmierstil in C

Allgemeines

• Benutzen Sie #define für symbolische Konstanten. Wenn ihr Wert verändert werden muss, braucht nur eine Zeile des Programms (die mit dem #define) geändert zu werden.
• Benutzen Sie ausschließlich Großbuchstaben für Konstanten und gemischte Schreibweise oder das Unterstreichungszeichen ( _ ) für Variable und Funktionsnamen. Namen wie GetData oder get_data sind leichter zu lesen als kleingeschriebene Namen ohne Unterstreichungszeichen (wie getdata).
• Passen Sie besonders beim doppelten Gleichbeitszeichen (= =) auf, das für die Abfrage auf Gleichheit benutzt wird. Wenn wir in einer if-Anweisung prüfen wollen, ob zwei Werte, A und B, gleich sind, tun wir das, wie unten links dargestellt. Rechts zeigen wir einen häufigen Fehler, die Benutzung eines einfachen Gleichheitszeichens, was eine völlig andere Bedeutung hat.

  if (A == B)                if (A = B)
    anweisung1;                 anweisung1;
  else                       else
    anweisung2;                 anweisung2;
  

  Was ist der Unterschied? Im linken Fall werden A und B verglichen und als wahr oder falsch bewertet, je nachdem, ob sie gleich sind oder nicht. Im rechten Fall handelt es sich um eine Zuweisung, die als Nebeneffekt ebenfalls einen Wert als Ergebnis liefert. Der Wert von B wird an A zugewiesen, und der neue Wert von A ist der Wert der Zuweisung. Er wird immer als wahr (ungleich null) bewertet, es sei denn, B ist gleich null.
• Benutzen Sie Funktionen, um Ihre Programme kurz und modular zu halten. Funktionen verkürzen das Hauptprogramm und machen dadurch den Gesamt­ablauf klarer. Ein Funktionsname sollte, wie alle anderen Namen auch, den Zweck erkennen lassen. Funktionen sollten verhältnismäßig kurz (50 bis 200 Zeilen) sein und großzügig kommentiert werden.
• C sieht nur minimale Fehlerprüfung vor, um dem Programmierer vollen Zugang zu der tatsächlich eingesetzten Maschine zu ermöglichen. Es wird unterstellt, daß Programmierer wissen, was sie tun. Es liegt in der Verantwortung des Programmierers, Arraygrenzen und Parametertypen zu überprüfen. Einige wenige sorgfältige Prüfungen können lange Testzeiten ersparen.

Über das Schreiben von Ausdrücken

• Einige der Vorrangregeln in C sind nicht einleuchtend. Falls Sie unsicher sind, benutzen Sie Klammern, um die Reihenfolge und Priorität der Bewertung anzugeben. Denken Sie jedoch daran, daß der Compiler die Bewertungsreihenfolge bestimmter Ausdrücke (solche, die nur die Operatoren &, /, ^, + oder * enthalten), selbst bei Anwesenheit von Klammern, frei wählen kann.
• Typumwandlungen können im allgemeinen benutzt werden, um die Angleichungen an den erforderlichen Typ zu erzwingen. Da Arithmetik mit unterschiedlichen Typen automatische Typangleichung mit sich bringt, die manchmal anders als erwartet ausfällt, benutzen Sie eine Umwandlung, um das Gewünschte zu erhalten.
• Es gibt keine Leistungseinbuße durch die Bewertung von Konstantenausdrücken, da sie zur Compilationszeit bewertet werden. Zum Beispiel wandelt der Compiler den Ausdruck a = 17.3 / 14.7 * PI / vals[i]; (vorausgesetzt, PI ist als 3.14159 definiert worden) in a = 3.697245371 / vals[i]; um.
• Einige C-Operationen können geschickt in vielfältiger Weise eingesetzt werden. Zum Beispiel kann das logische UND zweier Bedingungen manchmal durch das bitweise UND ersetzt werden, was möglicherweise schneller zu bewerten ist. Das ist jedoch nur angebracht, wenn Sie alle Bedingungen bewertet haben wollen.
• Seien Sie vorsichtig bei der Benutzung der additiven Operatoren ++ und --. Im allgemeinen sollten Sie nicht mehr als einen vor- oder nachgestellten Operator in einem einzelnen Ausdruck benutzen. Welches Ergebnis haben beispielsweise die folgenden Ausdrücke?

  a[i++] = a[--i];

  a[--i] = b[++i];

• Es ist leicht, unklare Ausdrücke zu schreiben. Selbst wenn diese Ausdrücke vom Compiler eindeutig interpretiert werden können, werden sie doch die meisten Programmierer verwirren. Wenn Sie sich nicht sicher sind, vereinfachen Sie es.

Programmformat

• Kommentare, die sich über mindestens eine Zeile erstrecken, sind linksbündig am Code ausgerichtet. Sie sollten beschreiben, was in den folgenden Programmzeilen bis zur nächsten Leerzeile geschieht.
  Ist ein Programmblock länger als 20 - 30 Zeilen, sollte ein Kommentar am Blockende auf den Blokanfang verweisen (z. B. /* Ende: while (x > 0) ... */ Funktionsbeschreibungen enthalten alle Parameter, Fehlerfälle und Rückgabewert. Ggf.muss auch angegeben werden, ob ein Parameter Eingabewwert, Ausgabewert oder beides ist. Die Beschreibung erfolgt direkt nach der Definition des Funktionskopfes noch vor den Block der Funktion.
• Formatieren Sie die Anweisungen durch Einrücken so, daß man die Anweisungs- und Blockstruktur erkennen kann. Achten Sie auf Lesbarkeit. Klammern oder Schlüsselworte zur Blockdefinition sollten in einer separaten Zeile stehen. Programmblöcke müssen durch Einrückung erkennbar (2 - 3 Leerschritte, keine Tabulatorzeichen) und linksbündig ausgerichtet sein. Beispiel:

     if (wert > 10)
       {
       /* tu was */
       /* tu noch was */
       }
  

  Code im globalen Kontext (z. B. die Definition einer global sichtbaren Funktion) darf nicht eingerückt sein.
  Eine Sprungmarke (Label) sollte eine einfache negative Einrückung zum vorhergehenden Code aufweisen.
• Trennen Sie Vereinbarungen und Anweisungen durch eine Leerzeile, auch wenn das nicht vom Compiler gefordert wird. Scheuen Sie sich nicht, weitere Leerzeilen einzufügen. Funktionen sollten vom vorhergehenden Code durch 2 - 3 Leerzeilen getrennt werden. Einzelne zusammengehörende Codezeilen können durch eine Leerzeile vom vorhergehenden Code getrennt werden.
  Die maximale Zeilenbreite des Quellcodes sollte maximal 70 - 75 Anschläge umfassen. Längere Zeilen müssen umbrochen werden. Der Umbruch eines Ausdrucks sollte an der Stelle eines Operators erfolgen, der keine höhere Priorität hat als der vorhergehende oder nachfolgende. Die umbrochene Zeile kann weiter eingerückt werden.
  Die Zeilentrennung bei Auflistungen (z. B. Initialisierung eier Array-Variablen oder Parameterliste beim Funktionsaufruf) sollte nach dem Trennungszeichen erfolgen. Der Eintrag in der Folgezeile wird linksbündig nach dem ersten Eintrag ausgerichtet.
• Vermeiden Sie es, zusammengesetzte Anweisungen in eine Zeile zu schreiben. Ausdrucks­anweisungen, die einen Bezug aufeinander haben, können unter Benutzung des Kommaoperaters verknüpft werden. Ausdrucksanweisungen, die keinen Bezug zueinander haben, haben Anspruch auf eigene Zeilen.
• Vermeiden Sie es, den Anweisungsteil einer Schleifen- oder Entscheidungsanweisung in dieselbe Zeile zu schreiben wie den Schleifensteuerungsausdruck. Die zwar kürzere Form ist schlechter lesbar und anfälliger gegen Fehler wie das irrtümliche Einfügen einer leeren Anweisung.
• Vergessen Sie nicht, bedingte Ausdrücke in Klammern einzuschließen. Denken Sie auch daran, daß dem while kein "do" folgt und dem if kein "then"; das Einfügen dieser Schlüsselwörter verursacht Syntaxfehler.
• Präprozessoranweisungen:
  Pfadangaben bei #include-Anweisungen erfolgen relativ zum Projektverzeichnis. Absolute Pfade sind verboten. Projektspezifische Include-Dateinamen stehen zwischen "...". Spitze Klammern sind für Standard-Headerfiles und projektübergreifende Dateien reserviert. Der Name einer Headerdatei darf sich nur in der Dateiendung von der Implementierungsdatei unterscheiden (z. B.: "foo.h" gehört zu "foo.c").
  Namen von Makros dürfen nur Grossbuchstaben und das Unterstreichungszeichen enthalten. Alle Makros zur bedingten Compilierung müssen im Dateikopf und der Projektdokumentation beschrieben werden.
  In einer Header-Datei müssen Deklarationen in folgender Reihenfolge stehen: Makros, Typen, globale Variable, lokale Variable (static), Prototypen lokaler Funktionen, globale Funktionen, lokale Funktionen.
• Schließlich, unterliegen Sie nicht der Versuchung vieler C-Programmierer, herauszufinden, wie man ein Programm in der knappsten möglichen Form schreiben kann. Wenn Sie unbedingt das Bedürfnis haben, tun Sie es, aber werfen Sie das Programm anschließend weg, denn es ist nicht mehr lesbar - oder nehmen Sie am Obfuscated C Contest teil.

Ein paar Regeln zur Schreibweise

• Delimiter und Ausdrücke
  Delimiter von Statements (der Strichpunkt) oder Variablen (das Komma) dürfen nicht unmittelbar einem Leerzeichen folgen, müssen aber von einem Zeilenvorschub, einem Leerzeichen oder weiteren Delimitern gefolgt werden.
• Trennzeichen in zusammengesetzten Datentypen
  Trennzeichen für zusammengesetzte Datentypen (also z.B. der Punkt beim Spezifizieren der Komponente einer struct oder union in C) dürfen weder direkt vor einem Leerzeichen stehen noch direkt von einem Leerzeichen gefolgt werden.
• Leerzeichen und Zuweisungsoperator
  Der Zuweisungsoperator muss zwischen zwei Leerzeichen oder zwischen einem Leerzeichen und einem Zeilenvorschub stehen.
• Leerzeichen und unäre Operatoren
  Unäre Operatoren (z.B. der Adressoperator & oder der Inhaltsoperator *) dürfen von ihrem Operanden nicht durch ein Leerzeichen getrennt werden.
• Unäre Operatoren als Teil von Datendeklarationen
  Ein unärer Operator, der in der Bezeichnung einer Variablen vorkommen kann, darf vom Variablenbezeichner nicht getrennt werden.
• Leerzeichen und biäre Operatoren
  Biären Booleschen Operatoren (z. B. &&, ||) muss ein Leerzeichen direkt vorangehen und eines direkt nachfolgen. Die Leerzeichen um biäre Operatoren darf visuell nicht den Vorrangregeln arithmetischer Ausdrücke wiedersprechen . Ein Leerzeichen muss entweder auf beiden Seiten des Operators stehen oder auf keiner Seite.
• Empfehlung zur Klammersetzung
  Eine öffnende eckige oder runde Klammer sollte einem Leerzeichen, Zeilenvorschub, einer anderen Klammer oder einem Funktions-/Variablennamen folgen und nicht direkt von einem Leerzeichen gefolgt werden. Eine schliessende eckige oder runde Klammer sollte nicht direkt hinter einem Leerzeichen stehen und sollte direkt von einem Trennzeichen, Delimiter oder einer weiteren Klammer gefolgt werden. Vor öffnenden Klammern, welche die Parameter vom Namen einer Funktion trennen, sollte kein Leerzeichen stehen. Zwischen einem Schlüsselwort (if, while, do, etc.) und einer öffnenden Klammer muss ein Leerzeichen stehen.

Über das Schreiben leicht lesbarer Programme

• Zusammenhalt: Eine Funktion sollte nur eine Aufgabe ausführen und alle Anweisungen in der Funktion sollten auf diese Aufgabe bezogen sein. Wenn die Wirkungsweise der Funktion nicht in einem einzigen Satz beschrieben werden kann, versucht die Funktion, zu viel zu tun.
• Allgemeingültigkeit Eine Funktion sollte ihre eine Aufgabe gut erfüllen. Eine Sortierroutine sollte z.B. für alle Eingabemengen gut arbeiten und Fehlerfälle (wie wenn keine zu sortierenden Elemente vorhanden sind) angemessen behandeln.
• Einfachheit: Eine Funktion sollte ihre Aufgabe auf die einfachst mögliche Weise erledigen; versuchen Sie nicht, durch übertriebenes Ausfeilen des Codes noch ein oder zwei Operationen einzusparen. Im allgemeinen wird ein Wechsel des Algorithmus mehr zur Effizienz beitragen als irgendwelche Manipulationen am Code.
• Kürze: Funktionen, die eine einzelne Aufgabe in einfacher Weise erledigen, sind im allgemeinen nicht lang. Es bewährt sich, Funktionen auf ca. 25 bis 200 Zeilen) zu beschränken. Natürlich können auch zu viele kleine Funktionen ein Programm zu sehr zerreißen und damit die Lesbarkeit und die Effizienz des Programms ruinieren. Die meisten Programmierer schreiben jedoch eher zu lange als zu kurze Funktionen.
• Dokumentation: Jede Funktion hat Anspruch auf einen Kommentar, der ihm Aufgabe beschreibt. Die Parameter und lokalen Variablen der Funktion sollten ebenfalls kommentiert werden. Häufig genügt ein einziger Satz zur Beschreibung der Funktion oder Variablen. Schreiben Sie die Kommentare immer gleichzeitig mit dem Code, und warten Sie nicht, bis die Funktion fertig geschrieben ist.

Schreiben von Makros

• Ersetzen Sie einfache Funktionen aus Effizienzgründen durch Makros. Achten Sie jedoch darauf, daß Sie nicht versuchen, zu viel in einem Makro zu tun. Es lohnt sich nicht, eine Funktion in ein Makro umzuschreiben, wenn der Verwaltungsaufwand des Funktionsaufrufs gering im Vergleich zu dem ist, was die Funktion ausführt.
• Ersetzen Sie, um den Code zu vereinfachen, komplizierte oder verwirrende Ausdrücke durch Makros. Durch das Makro erhält der Ausdruck einen Namen, was der Lesbarkeit dient. Dies ist besonders wichtig, wenn der Ausdruck an mehreren Stellen vorkommt.
• Schreiben Sie Makros, die in Ausdrücke und nicht in Anweisungen umgewandelt werden. Dadurch erreichen Sie, daß der Makroaufruf überall dort verwendet werden kann, wo auch ein Funktionsaufruf stehen kann. Wenn das nicht möglich ist, schließen Sie den Text des Makros in geschweifte Klammern ein, Sie dürfen dann allerdings das Makro nicht mit einem Semikolon abschließen.
• Vermeiden Sie Seiteneffekte in Makroaufrufen, unterstellen Sie nie, daß Argumente nur einmal bewertet werden, und stellen Sie keine Vermutungen darüber an, in welcher Reihenfolge Argumente bewertet werden. Diese Regeln gelten auch für Funktionen, da es manchmal nicht möglich ist, zu entscheiden, ob ein Aufruf einem Makro oder einer Funktion gilt.
• Klammern Sie Ausdrücke innerhalb eines Makroersatztextes, um sich gegen unerwartete Ergebnisse bei der Makroumwandlung zu schützen. Makrotexte, die in Ausdrücke umgewandelt werden, sollten ebenfalls geklammert werden.

Zeiger und Arrays

• Benutzen Sie Arrays mit Zeigern auf Zeichenketten anstatt zweidimensionaler Arrays, wenn die Zeichenketten unterschiedlich lang sind Zur Speicherzuweisung für die Zeichenketten sollten Sie malloc benutzen, um einiges von dem sonst bei jeder Zeichenkette vergeudeten Speicherplatz einzusparen. Merken Sie sich jedoch, daß bei der Vereinbarung eines Arrays aus Zeigern nicht automatisch Speicherplatz für das, worauf die Zeiger zeigen, zugewiesen wird.
• Fragen Sie den Rückgabewert von malloc immer ab. Unterlassen Sie das, können Sie sich ernsthafte Schwierigkeiten bereiten, die in den meisten Fällen zu einem Abbruch Ihres Programms durch das Betriebssystem führen, insbesondere, wenn Sie versuchen, mit einem Zeiger auf NULL Speicherplatz zuzuweisen. Es kann sein, daß Sie nichts Sinnvolles mehr tun können, wenn der verbliebene dynamische Speicher nicht mehr aus- reicht; die Entscheidung, das Programm dann abzubrechen, sollte jedoch bei Ihnen liegen. Die allgemeine Regel besagt, daß maschinennahe Routinen wie solche, die malloc aufrufen, dem Aufrufenden mitteilen sollten, daß es Schwierigkeiten gibt. Der aufrufende Teil sollte sich dann um den Fehler kümmern.
• Benutzen Sie typedef, um Vereinbarungen und Umwandlungen lesbar zu gestalten. Selbst wenn Sie in der Lage sind, komplexe Vereinbarungen zu verstehen, wird es unter den Lesern Ihres Programms sicher welche geben, die es nicht können.

Benutzung selbstdefinierter Typen

• Benutzen Sie Aufzählungstypen, wenn eine Variable einen Wert aus einer Menge von Werten annehmen kann. Sie bieten eine bequeme Möglichkeit, Konstanten zu definieren, fördern die Lesbarkeit und ermöglichen zusätzliche Typprüfung durch den Compiler. Beachten Sie jedoch, daß Aufzählungstypen keine Ganzzahlen sind und erst in geeigneter Weise umgewandelt werden müssen, wenn sie als Ganzzahlen benutzt werden sollen.
• Benutzen Sie Strukturen, wenn Sie Daten, die in einem engen Zusammenhang stehen, speichern wollen. Strukturen bieten außerdem eine weitere Möglichkeit, Informationen zu verbergen, da sie im Ganzen verarbeitet werden können, ohne daß man sich um den Inhalt ihrer Felder kümmern muß. Benutzen Sie Varianten, wenn ein Speicherplatz verschiedene Typen aufnehmen soll.
• Beachten Sie den Unterschied zwischen Strukturen und Varianten, der darin besteht, daß jedem Glied einer Struktur Speicherplatz zugewiesen wird, bei Varianten jedoch nur ein Platz entsprechend dem längsten Feld zugewiesen wird. Sie können nur jeweils einen Wert in einem Feld einer Variante speichern.
• Unterstellen Sie nie, daß die Felder einer Struktur fortlaufend gespeichert sind. Strukturen werden oft aufgefüllt, um Ausrichtungsnotwendigkeiten zu erfüllen. Die Annahme, daß nicht aufgefüllt wird, führt zu nicht portierbarem Code.

Dynamische Datenstrukturen

• Dynamische Datenstrukturen ersparen dem Programmierer viel Zeit. Sie haben außerdem die angenehme Eigenschaft, daß sie Speicher für beliebige Wertezusammenstellungen bereitstellen, wobei nur Speicherplatz für die tatsächlich gespeicherten Werte verbraucht wird. Schließlich sind sehr viele Algorithmen am einfachsten zu implementieren, wenn dynamisch zugewiesener Speicher zur Verfügung steht.
• Dynamische Datenstrukturen sind jedoch zur Laufzeit nicht notwendigerweise effizienter. Normalerweise müssen das Betriebssystem und die Laufzeitumgebung von C den frei zur Verfügung stehenden Speicherplatz so verwalten, daß Knoten jeder Größe in beliebiger Reihenfolge angefordert und freigegeben werden können. Bei Arrays fester Größe entlasten wir das System zur Laufzeit, müssen jedoch als Ausgleich dafür den Speicherbedarf im voraus genau angeben.
• Speicherzuweisung für dynamische Datenstrukturen kann versagen; daher müssen wir den Rückgabewert von malloc prüfen. Diese Funktion versagt (gibt NULL zurück), wenn im System kein Speicher mehr vorhanden ist.

Auswahl der geeignetsten Bibliotheksfunktion

• Benutzen Sie nach Möglichkeit immer zeichenweise Ein- und -ausgabe. Die Funktionen getc, putc, getchar und putchar sind effizienter und einfacher zu benutzen als die anderen Bibliotheksfunktionen.
• Benutzen Sie bei Anwendungen, bei denen eine zeilenweise Verarbeitung ihrer Eingabe nahe liegt, die zeilenorientierten Funktionen fgets, fputs, gets und puts. Sie sind nicht so effizient wie die Zeichen-E/A-Funktionen, sind aber effizienter als die formatierten E/A-Funktionen scanf, printf. Passen Sie jedoch bei Zeilen auf, die länger als erwartet sind.
• Sparen Sie sich die formatierten Funktionen für die Fälle auf, in denen sie wirklich benötigt werden: Lesen und Schreiben formatierter Ein- und Ausgabe. Wegen des zusätzlichen Aufwandes beim Analysieren der Formatzeichenkette sind sie erheblich langsamer und erzeugen wesentlich mehr Code als alle anderen E/A-Funktionen.
• Benutzereingaben sind grundsätzlich als fehlerbehaftet und unkorrekt zu betrachten.

9.2 Fallen in C

Feldgrenzen

Dumme Fehler können auch entstehen, wenn im Speicher mehrere Strings hintereinander stehen und man mit der Länge nicht aufpaßt. Schreibt man nämlich die abschließende ' \ 0 , über den ersten String hinaus, steht sie unter Umständen als erstes Zeichen im zweiten String, sodaß dieser als Leerstring erscheint, obwohl er explizit nicht belegt wurde:

char s1[10], s2[12];

        | a | b | c | d | e | f | g | h | i | j |\0 | x | y | z |\0 |  |  |
         ^s1                                     ^s2

printf("%s\n",s1);     -->   "abcdefghij"
printf("%s\n",s2);     -->   ""

int getline(char buf[], int len);    /* Deklaration (Prototyp) von getline */

main ()
  {
  int ll;
  char string[80];

  ll = getline(string, sizeof string); /* Aufruf von getline */
  return 0;
  }

int getline(char s[], int lim);
  {
  int i = 0;
  for(i=0; i<lim-1; i++)
    s[i] = ....;
  s[i] = '\0';
  return i;
  }

• Felder immer groß genug wählen
• Feldgrenzen immer abfragen
• Bei Strings auf die abschließende'\0'achten

Falsch gesetzte Semikolons

• Einer der häufigen Fehler das Vergessen des Semikolons am Ende der Anweisung. Dummerweise merkt der C-Compiler das oft erst in der nächsten Zeile und weist erst dann darauf hin. Aber immerhin handelt es sich um einen Compile-Fehler.
• Auch das Vergessen des Semikolons am Ende einer Strukturdeklaration kann merkwürdige Auswirkungen haben. Wird gleich anschließend das Hauptprogramm ohne Returntyp definiert, interpretiert der Compiler die Struktur als Returntyp des Hauptprogramms.
• for( ... ; ... ; ...) ;
  { ... }
  beendet Schleifenrumpf, analog bei while
• Ein ähnliches Problem ist das Vergessen der Blockklammer in Kontrollstrukturen:

  while (i > O)
    tuwas();
    i++;
  

  Hier besteht die Schleife nur aus dem Kopf mit der Bedingung und dem Aufruf der Funktion tuwas() Der Zähler i++ ist bereits außerhalb der Schleife - also wieder eine Endlos-Schleife!

Falsche Einrückung

if (i > j)
  if (k < 100)
    tuwas();
else
  tuwasanderes();

if (i > j)
  {
  if (k < 100)
    tuwas();
  }
else
  tuwasanderes();

Die switch-Falle

switch (c)
  {
  case '1': tuwas(); break;
  case '2': tudies(); break;
  case '3': tujenes(); break;
  default:  printf("error\n"); break;
  }

#define CASE break;case
#define DEFAULT break;default

switch (c)
  {
  CASE '1': tuwas();
  CASE '2': tudies();
  CASE '3': tujenes();
  DEFAULT:  printf("error\n");
  }

Float-Ausdrücke

Vergleichsoperator vs. Zuweisungsoperator

char s1(100), s2[100];

/* s1 nach s2 kopieren (bis Stringende '\0') */
while (s2[i] = s1[i])
  i++;

Reihenfolge der Auswertung

• i++ * i++ undefiniert
• Reihenfolge nur definiert bei &&, ||, Komma und ?:, dort sogar bedingte Auswertung
• Alle Argumente einer Funktion werden in unbestimmerter Reihenfolge vor dem Aufruf ausgewertet

Eingabe-Probleme

#include 

int i, c, ret;
ret = scanf("%d",&i);         /* gepufferte Eingabe */
if(ret != 1) error();        /* Fehlerbehandlung */
while (getchar() != '\n';    /* Eingabepuffer leeren */
getchar();                    /* Einzelzeichen lesen */

fgets(buf, MAX, stdin);
sscanf(buf, .... );

Preprozessor

• Ein mit #if ausgeklammertem Text muß aus gültigen Preprozessortokens bestehen
• Makros können ebenfalls Probleme bereiten: #define sqr(x) x = x*x Hier wird ein Square-Makro definiert, der das Quadrat einer Zahl ermitteln soll.
  Dies funktioniert auch für Variablen ganz gut: int i = 10; ... sqr(i); ...
  Nun steht in i das Quadrat, also 100. Benutzt man dieses Makro aber für einen Wert (sqr(10);), so macht die Zuweisung Probleme. Also sollte man die Zuweisung im Makro unterlassen: #define sqr(x) x*x
• i = sqr(10); funktioniert nun. Ruft man dieses Makro nun aber mit einem Ausdruck auf, gibt es wieder Probleme: i = sqr(2 + 8); wird zu 2 + 8 * 2 + 8 ersetzt und da Punktrechnung vor Strichrechnung geht, ist das Ergebnis 2 + 16 + 8 = 26, also falsch. Die zweite Regel sollte also lauten, Klammern zu verwenden:

  #define sqr(x) ((x)*(x))
  

  Doch damit ist beispielsweise sqr(++i); noch nicht gelöst, da nun ++i zweimal ausgeführt wird, und zwar ++i * ++i. Dieses Problem ist mit Makros nicht zu lösen. Also keine Zuweisungen oder andere Seiteneffekte in Makroaufrufen!

Konstante und Variable

• Bei const char *a und char *b ist a=b ok (Erlaubnis zum Ändern wird nicht übernommen), b=a ist dagegen falsch (Erlaubnis zum Ändern wird fälschlicherweise gegeben)
• Bei const int a und int b ist a=b falsch (Unerlaubte Änderung), b=a ist erlaubt (Verarbeitung nur einer Kopie)

(Null-)Pointer

• NULL ist nur #define NULL 0 - Automatische Typumwandlung
• Pointer sind keine Integer-Werte.
• Ein Zeiger muß immer mit einer gültigen Speicherplatzadresse initialisiert sein.

Arrays und Pointer

• In einer Datei char a[5], in der anderen extern char *a ist falsch, extern char a[] ist richtig
• Äquivalenz der Deklarationen char a[] und char *a nur bei formalen Argumenten von Funktionen
• char b[][] und char **b nicht äquivalent, letzteres verwendet real im Speicher vorhandene Pointer
• Aufzeichnen: Realer Speicher bei char **a, char *a[], char (*a)[], char a[][]
• Dynamische Allozierung mehrdimensionaler Felder: Am besten Allozieren eines Feldes mit Pointern und Allozieren jeder einzelnen Zeile

Dynamische Speicherverwaltung

• char *s; gets(s); ist falsch, da kein Speicher bereitsteht
• char *s="Hal",*t="lo!",*u=strcat(*s,*t) ist genauso falsch
• Mit free() freigegebener Speicher darf nicht mehr angesprochen werden

9.3 Modularisierung und Makefiles

Compiler und Linker

gcc -c foo.c            Erzeugen der Object-Dateien (*.o)
gcc -c bar.c
gcc -c test.c
gcc -o go *.o           Erzeugen des Executables (go)

-c         nur übersetzen, nicht linken
-Idir      Include-Dateien in dir suchen
-Wall      alle Warnungen aktivieren
-g         Debugging-Symbole erzeugen
-o file    fertiges Programm in file schreiben
-Olevel    Optimierungen einschalten, z. B. -O2
-foption   generelle Compiler-Optionen, z. B. -ffast-math
-llib      Bibliothek linken, z. B. bindet "-lm" die libm.o ein
-Ldir      Bibliotheken in dir suchen

Make

Das Make-Utility leistet das Gewünschte. Dem Make-Utility muss ein sogenanntes Makefile (Datei-Name: "Makefile", diese Schreibweise ist wichtig) bereit gestellt werden, das die Abhängigkeiten eines Projekts beschreibt: Module, Versionen (Debug-Version, Release-Version) sowie andere Informationen. Make erkennt anhand der Modifikations-Zeit der Dateien was sich geändert hat. Das Makefile beschreibt die Abhängigkeiten mittels "Targets" (engl. Ziele). Das Makefile bestehen aus einer Menge von Regeln zur Steuerung der Übersetzung. Sein Aufbau ist:

Ziel: Quelle Quelle ...
      Shellkommando
      Shellkommando
      ...

go: bar.o foo.o test.o
    gcc bar.o foo.o test.o -lm -lglib -o go
bar.o: bar.c
    gcc -Wall -O2 -c bar.c
foo.o: foo.c
    gcc -Wall -O2 -c foo.c
test.o: test.c
    gcc -Wall -O2 -c test.c
clean:
    rm -rf *.o

Ein Eintrag eines Makefiles sieht formal folgendermaßen aus:

Target_Name: <Dateien oder Sub-Targets von den dieses abhängt>
   <Tab-Zeichen>   <Regel zum erstellen dieses Targets>

Eine gemeine Falle für Anfänger ist, daß die zweite Zeile mit einem <tab> anfangen muß, und nicht mit Leerzeichen.

Beim Aufruf von make kann angegeben werden, welches Target man erstellen möchte. Make erzeugt dann alle hierfür nötigen Subtargets. Wird make ohne Parameter gestartet, wird das erste (oberste) Target aus dem Makefile erstellt. Im Beispiel oben werden dann foo.o, bar.o, test.o und go erzeugt.

Es gibt auch Targets, die keine Abhängigkeiten haben. Im obigen Makefile haben wir ein zusätzliches Target "clean", das dazu da ist, alle o-Files wieder sauber zu löschen. Somit kann man mit dem Kommando make clean wieder aufräumen.

Viele targets können nicht (wie oben) durch einen einzigen Befehl erzeugt werden, sondern benötigen mehrere Kommandos. In diesem Fall folgen auf die Zeile mit den Abhängigkeiten einfach mehrere Zeilen, die alle mit <tab> beginnen. Auch die Abhängigkeiten für ein target dürfen auf mehrere Zeilen verteilt sein.

Im Beispiel oben ist "go" gleichzeitig ein Target-Name und ein Datei-Name. make sieht darin keinen Unterschied. Auch die beiden Dateien foo.c und bar.c sind für make nichts anderes als Targets. Diese hängen von keinen anderen Targets ab, sind also immer aktuell, und es gibt auch keine Regel, um sie zu erzeugen. Würde nun beispielsweise die Datei bar.c nicht existieren, würde make feststellen, daß es das target bar.c, welches für bar.o benötigt wird, nicht erzeugen kann. Die Fehlermeldung lautet dementsprechend:

   
   make: *** No rule to make target `bar.c'. Stop.

Es ist möglich, in Makefiles Variablen (eigentlich sind es Makros) zu definieren und zu benutzen. Normalerweise verwendet man Großbuchstaben. Gebräuchlich sind beispielsweise folgende Variablen:

CC        der Compiler
CFLAGS    Compiler-Optionen
LDFLAGS   Linker-Optionen

VERSION = 3.02
CC      = /usr/bin/gcc
CFLAGS  = -Wall -g -DVERSION=\"$(VERSION)\"
LDFLAGS = -lm -lglib

OBJ = datei1.o datei2.o datei3.o datei4.o datei5.o

all: $(OBJ)
        $(CC) $(CFLAGS) -o go $(OBJ) $(LDFLAGS)

%.o: %.c
        $(CC) $(CFLAGS) -c $<

$@     Ziel
$<     erste Quelle
$ˆ     alle Quellen
$?     Quellen, die neuer sind als das Ziel

go:   $(OBJECTS)
$(CC) $ˆ -lm -lglib -o $@
%.o: %.c
$(CC) $(CFLAGS) -c $<

Module

#include <stdio.h>

/* Funktions-Prototypen */
int foo(int a, int b);
void bar(int a, int *result);

int main(void) 
  {
  int X = 2,Y = 3, res;
  res = foo(X, Y);
  printf("%d\n", res);
  bar(X, &res);
  printf("%d\n", res);
  return(0);
  }
  
int foo(int a, int b) 
  {
  return a + b;
  }
  
void bar(int a, int *result) 
  {
  *result = a;
  }

/* Testmodul */
#include <stdio.h>

/* Funktions-Prototypen */
int foo(int a, int b);
void bar(int a, int *result);

int main(void) 
  {
  int X = 2,Y = 3, res;
  res = foo(X, Y);
  printf("%d\n", res);
  bar(X, &res);
  printf("%d\n", res);
  return(0);
  }

int foo(int a, int b) 
  {
  printf("I am foo\n");
  return a + b;
  }
  
void bar(int a, int *result) 
  {
  printf("I am bar\n");
  *result = a;
  }

Besser ist es, die Prototypen in eine separate Datei zu schreiben, die man modul.h nennt (das "h" steht für "Header-Datei"). Für das Beispiel oben sieht die Header-Datei mdul.h so aus:

/* Funktions-Prototypen */
int foo(int a, int b);
void bar(int a, int *result);

/* Testmodul */
#include <stdio.h>
#include "modul.h"

int main(void) 
  {
  int X = 2,Y = 3, res;
  res = foo(X, Y);
  printf("%d\n", res);
  bar(X, &res);
  printf("%d\n", res);
  return(0);
  }

Bei größeren Systemen kann es durchaus vorkommen, dass einzelne Module die Funktionen anderer Module verwenden und daher deren Header-Dateien includieren. So kann es recht schnell zum mehrfachen Einbinden der Header-Dateien (mit entsprechen seltsamen Verhaltensweisen von Programm und Compiler) kommen. Mit den Präprozessor-Konstrukten #define und #ifndef kann man gewährleisten, dass eine Header-Datei jeweils nur beim ersten Mal effektiv includiert wird. Damit sieht unser Beispiel-Headerfile folgendermaßen aus:

#ifndef _MODUL_H_
#define _MODUL_H_
/* Funktions-Prototypen */
int foo(int a, int b);
void bar(int a, int *result);
#endif 
/* _MODUL_H_ */

Wir folgen der C/C++-Konvention, indem wir für die jeweiligen Symbole den Datei-Namen der Header-Datei verwenden und jeweils ein Unterline-Zeichen vorne und hinten anfügen. Ebenso wird der Punkt im Dateinamen durch das Underline-Zeichen ersetzt. Wenn Sie sich für jede Header-Datei an diese Konvention halten, kann nichts mehr schief gehen. Tun Sie es auch, wenn Sie der festen Überzeugung sind, dass keine Mehrfach-Inkludierung vorkommt. Beim #endif geben Sie als Kommentar die Bezeichnung zum zugehörigen Symbol der #ifndef-Direktive an. So wissen wir immer, zu welchem #ifdef ein #endif gehört.

Das Makefile zum Beispiel muss natürlich nun auch das Header-File berücksichtigen:

go: modul.o test.o
    gcc modul.o test.o -lm -lglib -o go
modul.o: modul.c modul.h
    gcc -Wall -O2 -c modul.c
test.o: test.c
    gcc -Wall -O2 -c test.c
clean:
    rm -rf *.o

Zum Inhaltsverzeichnis

Zum nächsten Abschnitt

Copyright © FH München, FB 04, Prof. Jürgen Plate

Letzte Aktualisierung: 10. Mär 2009