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?
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
>#ifndefFILE_H_
2
>#defineFILE_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
>#ifndefFILE_H_
2
>#defineFILE_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.
@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.
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 :)
Yalu X. schrieb:> Trotzdem ist diese Vorgehensweise vielleicht in speziellen Situtationen> sinnvoll. Dann würde mich ein Beispiel für eine solche Situtation> ebenfalls interessieren.
Vieleicht, wenn man zwei Dateien die dasselbe, aber "anders" oder für
andere Hardware machen...
Datei1.h
#define INTERFACE_H Datei1
...
Datei2.h
#define INTERFACE_H Datei2
So wäre sichergestellt, dass immer nur eine von beiden "aktiv" ist, und
die hilfreiche IDE zeigt sogar an, welche, wenn man den Mauszeiger über
"INTERFACE_H" schweben lässt.
Aber dasselbe könnte man über ein eigenständiges #define, unabhängig vom
Include Guard, genauso und m.M.n schöner, erreichen...
Dennis S. schrieb:> Es empfiehlt sich also, entweder Variablennamen mit der> Endung _h zu vermeiden oder den Text durch sich selbst zu ersetzen,> damit> er keine Änderung erfährt.
Wenn das tatsächlich die Begründung ist: Ganz schlechter Stil.
Wenn ich als Programmierer einen Fehler mache, soll der Compiler mir den
ankreiden.
Ich bin dem Compiler deswegen nicht böse.
Sonst könnte man ja gleich noch "-fpermissive" als
Default-Compiler-Option vorschlagen, damit der arme GCC nicht so viel zu
meckern hat.