Include Guard

Vergesslich schrieb:
> Hallo zusammen,
>
> ich wusste die Begründung für die folgende Variante von Include Guards
> in C mal, habe sie aber vergessen und finde auch keine Erklärung mehr.
> Wer weiß mehr?
>
>

1

> #ifndef FILE_H_

2

> #define FILE_H_ FILE_H

3

> 

4

> #endif

5

>

du willst verhindern, dass während der Compilierung eines C-Files der 
Inhalt eines Header Files (indirekt) mehrmals eingebunden wird.
Meistens ist diese Mehrfach-Inclusion harmlos, es gibt aber auch Dinge, 
die vom C-Standard her nicht mehrfach erlaubt sind, wie zb die 
Deklaration von Strukturen.

Vergesslich schrieb:
> Hallo,
>
> es geht nicht um den Sinn von Include Guards

ah ok.

> sondern um die "spezielle"
> Form von oben! Üblich ist ja meins Wissens eher
>
>

1

> #ifndef FILE_H_

2

> #define FILE_H_

3

> 

4

> #endif

5

>

Ist völlig wurscht.
Der entscheidende Punkt ist ja nicht, in welchen Ersatztext das Makro 
expandiert, sondern nur, dass es überhaupt definiert ist.

WEnn du willst kannst du auch

1

#ifndef FILE_H_

2

#define FILE_H_   Hamstibamsti

3

4

...

5

6

#endif

schreiben. Der Makroinhalt wird ja nie ausgewertet, sondern es wird 
immer nur abgefragt, ob ein Makro mit diesem Namen jemals definiert 
wurde.

Vergesslich schrieb:
> @Karl Heinz: Ich bin in der Regel geneigt dir alles zu glauben, aber ich
> bin mir ganz ganz ganz sicher, dass es einen Grund dafür gibt.. :-D Ich
> vermute mal Richtung Portabilität bei verschiedenen Compilern.

Portabilität kann kein Grund sein.
Denn es ist selbstverständlich erlaubt, dass ein Makro zu 'nichts' 
expandiert.

Ich wüsste keinen Grund, warum man ausgerechnet diese Form wählen 
sollte.

Vergesslich schrieb:
> @Karl Heinz: Ich bin in der Regel geneigt dir alles zu glauben, [...]

Du kannst ihm das ruhig glauben.
Mit

        #ifndef FILE_H
bzw.
        #ifdef FILE_H

wird abgefragt, ob die Konstante überhaupt definiert wurde. Der Inhalt 
wird aber nicht gepfrüft. Schreibe also das rein, was Dir am besten 
gefällt.

Minimalisten bevorzugen halt

        #define FILE_H

Aber das ist nur eine Frage des Geschmacks.

Dass man dem Guard-Makro noch einen Inhalt gibt, habe ich auch noch nie
gesehen. Da es kaum jemand so macht, kann es auch kaum einen triftigen
Grund dafür geben.

Trotzdem ist diese Vorgehensweise vielleicht in speziellen Situtationen
sinnvoll. Dann würde mich ein Beispiel für eine solche Situtation
ebenfalls interessieren.


Peter II schrieb:
> --- Datei1.h ---
> #include Datei2.h
>
> --- Datei2.h ---
> #include Datei1.h

Die indirekte Rekursion von Include-Files ist aber auch mit Guards
böse, da sie zu undeklarierten Typen oder Variablen führen kann, obwohl
diese eigentlich ganz klar im includeten Header-File deklariert sind.

Wenn man das erste Mal mit diesem Problem konfrontiert wird, sucht man
eine halbe Ewigkeit nach der Ursache. So war's zumindest bei mir :)

Nachdem ich die Diskussion bisher nur lesend verfolgt habe:

Das Ganze kenne ich aus dem Buch "Der C++ Programmierer". Zitat 
(sinngemäß):

1

Es kann sein, dass zufällig derselbe Name im Programmcode auftritt, weil

2

der Dateiname meistens mit dem Dateiinhalt zu tun hat. #define dient zur

3

Textersetzung oder definiert etwas als logisch wahr. Das zweite Auftreten

4

ist für den Compiler nicht verständlich, weil anstatt fn_h eine 1 (= wahr)

5

gesehen wird. Es empfiehlt sich also, entweder Variablennamen mit der

6

Endung _h zu vermeiden oder den Text durch sich selbst zu ersetzen, damit

7

er keine Änderung erfährt.

Gruß
Dennis

Ich habe lediglich zitiert... :-)