Include-Files (C)

2004-08-29T18:22:50Z

83.64.199.107: /* Problemlösung mit Makros */

Include-Files in C/C++ enthalten typischerweise Informationen, die im Rahmen der Kompilierung verschiedener anderer Quelltexte (mehrfach) benötigt werden.

Wer bisher hauptsächlich kleinere (Assembler-) Programme für Mikrocontroller realisiert hat und sich nun langsam an größere Projekte heranwagt und deshalb auf C umsteigt, ist gut beraten, die Möglichkeiten sinnvoll einzusetzen, die Include-Files in C bieten. Dabei gilt es allerdings auch, einige Fallgruben zu vermeiden - mehr dazu in diesem Artikel.

== Verwendung von Include-Files ==

Die Verwendung von Include-Files in [[C]] und [[C-Plusplus|C++]] führt in der Regel zu besser strukturierten und damit besser wartbaren Programmen. Indem bestimmte, zentrale Informationen nur ein einziges Mal hinterlegt werden, fällt insbesondere bei Änderungen weniger Aufwand an.

Der übliche Suffix für Include-Files ist "<tt>.h</tt>", manchmal auch "<tt>.hpp</tt>" (für C++), und die ''Verwendung'' eines Include-Files ist sehr einfach:
#include "xyz.h"

Wird der Dateiname in spitze Klammern gesetzt, dann sucht der Präprozessor die Datei nicht im aktuellen Verzeichnis, sondern im Standard-Include-Pfad des Compilers:
#include <io.h>

Dabei sind auch relative Verzeichnisangaben erlaubt:
#include <avr/timer.h>

== Probleme bei Include-Files ==
In Include-Files werden mitunter Informationen aus anderen Include-Files benötigt und es ist an der Verwendungsstelle eines Include-Files oft nicht das Wissen über die möglicherweise sehr komplexen Abhängigkeiten vorhanden. Nachfolgend wird ausgehend von einer typischen Problemstellung eine Standardtechnik erläutert, die hilft, das Wissen um Abhängigkeiten an der Verwendungsstelle überflüssig zu machen:

Angenommen, es existieren zwei Datenstrukturen für die es die Typdefinitionen <tt>s1_t</tt> und <tt>s2_t</tt> gibt, die jeweils entsprechenden Include-Files hinterlegt sind, also
<tt>s1.h</tt>:
<pre>
/* Definition der Datenstruktur s1 */
struct s1 {
...
};
typedef struct s1 s1_t;
...
/* Funktions-Deklarationen */
void foo(s1_t);
...
</pre>

Die Datei <tt>s2.h</tt> sieht so aus:
<pre>
/* Definition der Datenstruktur s2 */
struct s2 {
...
};
typedef struct s2 s2_t;
...
/* Funktions-Deklarationen */
s2_t *bar();
...
</pre>

Eine bestimmte Applikation benötigt nun beide Struktur- und Funktions-Definitionen und inkludiert entsprechend beide Dateien, es gibt also eine kompilierbare Datei (z.B. <tt>main.c</tt>) die wie folgt aussieht:
<pre>
#include "s1.h"
#include "s2.h"
...
int main() {
s1_t a;
s2_t *b;
...
foo(a);
b = bar();
...
}
</pre>
So weit, so gut.

Nun kommt es eines Tages zu einer Änderung, die darauf hinausläuft, dass die erste Struktur die zweite als Element enthält. Das heißt die Datei <tt>s1.h</tt> sieht nun wie folgt aus:
<pre>
struct s1 {
s2_t x;
...
}
...
/* Funktions-Deklarationen */
void foo(s2_t);
...
</pre>
Daraufhin wird sich <tt>main.c</tt>(!) nicht mehr kompilieren lassen, da bei der Verarbeitung von <tt>s1.h</tt> (noch) nicht bekannt ist, worum es sich um bei <tt>s2_t</tt> handelt. (Es könnte ja auch einfach nur ein Tippfehler sein!)

Da es in der Praxis einen immensen Pflegeaufwand auslösen kann, wenn Änderungen in Include-Files Änderungen in vielen weiteren Dateien erfordern (dem Wesen nach soll ja eine Include-Dateien eine Information zentral für viele andere Dateien bereitstellen), muss nach einem Ausweg gesucht werden.

Dieser könnte so aussehen, dass man "vorsorglich" die Beschreibung der verwendeten Datenstruktur in <tt>s1.h</tt> inkludiert:
<pre>
#include "s2.h"
struct s1 {
s2_t x;
...
};
...
/* Funktions-Deklarationen */
void foo(s2_t);
...
</pre>

Inkludiert das Hauptprogramm lediglich <tt>s1.h</tt>, wäre nun alles in Ordnung, wenn aber beide Dateien inkludiert werden, beschwert sich der Compiler über die doppelte Definition der Datentypen. (Die doppelte Deklaration von Funktionen ist kein Fehler, wenn sie übereinstimmend erfolgt.)

== Problemlösung mit Makros ==
Die übliche und - fast - perfekte Lösung des Problems besteht darin, den eigentlichen Inhalt eines Include-Files vor einer zweiten Verarbeitung durch eine ''bedingte Kompilierung'' zu schützen.
Bei der bedingten Kopilierung handelt es sich ebenfalls um ein Feature des [[C-Präprozessor]]s und es wird hier wie folgt auf die Datei <tt>s2.h</tt> angewendet:
<pre>
#ifndef S2_h
#define S2_h
struct s2 {
...
};
...
/* Funktions-Deklarationen */
s2_t *bar();
...
#endif
</pre>
Da das beschriebene Problem in größeren Programmsystemen auch in Bezug auf die andere Struktur auftreten könnte, sollte man die Datei <tt>s1.h</tt> vorsorglich mit einem ähnlichen Schutz ausstatten:
<pre>
#ifndef S1_h
#define S1_h
#include "s2.h"
struct s1 {
s2_t x;
...
};
...
/* Funktions-Deklarationen */
void foo(s2_t);
...
#endif
</pre>
Der nette Nebeneffekt ist, dass es damit auch keine Rolle spielt, in welcher Reihenfolge beide Dateien in <tt>main.cpp</tt> inkludiert werden.

== Zusammenfassung der Regeln ==
Kochrezeptartig kann man beim Schreiben und Verwenden von Include-Files auch einfach die folgenden Regeln anwenden:
* Wird die externe Schnittstelle (Datenstrukturen, Funktions-Deklarationen) eines Moduls ''XYZ'' in einem Include-File <tt>xyz.h</tt> beschrieben, so sollte ein bestimmter Makroname (z.B. <tt>XYZ_h</tt>) für die Steuerung der tatsächlichen Verarbeitung des Include-Files reserviert werden(*1).
* Der Include-File selbst testet (und definiert anschließend) diesen Makro, um so eine doppelte Verarbeitung zu vermeiden.
* Wird in einer Kompilierung das Modul ''XYZ'' verwendet (= eine seiner Datenstrukturen oder Funktionen), wird auch der Include-File <tt>xyz.h</tt> in diese Kompilierung eingeschlossen.
* Verwendet das Modul ''XYZ'' '''intern''' ein weiteres Modul ''UVW'', so wird '''dessen''' Include-File <tt>uvw.h</tt> im Include-File <tt>xyz.h</tt> eingeschlossen.

Die beschriebenen Regeln funktionieren zufriedenstellend und entlasten vor allem Programm-Code, welcher Include-Files lediglich einschließt, vom Wissen über komplexe Zusammenhänge zwischen einzelnen Modulen. Ferner spielt die Reihenfolge, in der man Include-Files verwendet, keine Rolle und man kann sie beliebig gruppieren und ordnen, so wie es am übersichtlichsten ist(*2).

== Gegenseitige Bezugnahme ==
Eine Ausnahme von der allgemeinen Regel liegt vor, wenn sich zwei Datenstrukturen gegenseitig verwenden (was nur über Zeiger der Fall sein kann).
Alle wie auch immer gearteten Versuche, diese beiden Strukturdefinitionen und Funktionsprototypen in zwei verschiedene Include-Files aufzuteilen, also z.B. <tt>s1.h</tt>
<pre>
#ifndef S1_h
#define S1_h
#include "s2.h"
struct s1 {
struct s2 *px;
...
};
typedef struct s1 s1_t;
...
s2_t *bar(s1_t);
#endif
</pre>
und <tt>s2.h</tt>
<pre>
#ifndef S2_h
#define S2_h
#include "s1.h"
struct s2 {
struct s1 *yp;
....
};
...
void foo(s2_t);
#endif
</pre>
werden scheitern - mit und ohne dem beschriebenen Schutz vor doppelter Verarbeitung!

Die pragmatische Lösung ist hier, alles in einem '''gemeinsamen''' Include-File <tt>s1_s2.h</tt> zu hinterlegen:
<pre>
#ifndef S1_S2_h
#define S1_S2_h
struct s1 {
struct s2 *px;
....
};
typedef struct s1 s1_t;

struct s2 {
struct s1 *yp;
....
};
typedef struct s2 s2_t;
...
void foo(s2_t);
s2_t *bar(s1_t);
#endif
</pre>
Das ist insofern sinnvoll, als ein Programm, welches die eine Struktur kennen muss, stets auch die andere benötigt. Die Aufteilung in zwei Include-Files würde also keinen echten Vorteil bringen.

Eine Ausnahme kann lediglich gemacht werden, wenn auf die jeweils andere Struktur ausschließlich über Zeiger(*3) zugegriffen wird, dann sind auch zwei Include-Files möglich, nämlich <tt>s1.h</tt>
<pre>
#ifndef S1_h
#define S1_h
struct s2; /* Vorausdeklaration */
struct s1 {
struct s2 *px;
...
};
typdef struct s1 s1_t;
...
struct s2 *bar(s1_t);
</pre>
und <tt>s2.h</tt>
<pre>
#ifndef S2_h
#define S2_h
struct s1; /* Vorausdeklaration */
struct s2 {
struct s1 *py;
...
};
typdef struct s2 s2_t;
...
void bar(struct s1 *);
</pre>
Anstatt den jeweils anderen Include-File einzuschließen, sind nun die oben gezeigten Vorausdeklarationen vorzumehmen. (Allerdings sind damit die Typdefinitionen <tt>s1_t</tt> und <tt>s2_t</tt> nicht verfügbar, die Bezugnahme auf die jeweils andere Struktur kann nur über <tt>struct s1</tt> und <tt>struct s2</tt> erfolgen.)

----
* 1: Die genaue Beziehung zwischen dem Makro-Namen und dem Modul- (oder Struktur-) Namen ist dabei nicht so bedeutend. Die übliche Konvention, solche "Steuer-Makros" mit "<tt>_h</tt>" oder "<tt>_H</tt>" zu beenden, soll nur helfen, "zufällige" Kollissionen mit Makros zu vermeiden, die einen anderen Zweck haben.
* 2: Eine alphabetische Sortierung ist z.B. hilfreich, um bei einem Kompilierfehler schnell überprüfen zu können, ob vielleicht nur ein bestimmter Include-File vergessen wurde.
* 3: Bei der Verwendunng von C++ gilt das zusätzlich für die Bezugnahme über Referenzen.

Mikrocontroller.net - Benutzerbeiträge [de]

Include-Files (C)