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
|
Gruß
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: > Wer weiß mehr? --- Datei1.h --- #include Datei2.h --- Datei2.h --- #include Datei1.h
Hallo, es geht nicht um den Sinn von Include Guards, sondern um die "spezielle" Form von oben! Üblich ist ja meins Wissens eher
1 | #ifndef FILE_H_
|
2 | #define FILE_H_
|
3 | |
4 | #endif
|
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.
:
Bearbeitet durch User
@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.
:
Bearbeitet durch Moderator
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...
Mhhh... ich bin mir so sicher, das mal gesehen zu haben! Aber ich komme einfach nicht mehr drauf. Trotzdem Danke für die Diskussion.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.