#include Guard vs #pragma once

[dot]

Michael E. schrieb:

Edit: Achso, beim ersten Verarbeiten der Datei wird gespeichert, dass das ifnef ein Include Guard ist?

Exakt, genau darum gehts bei dem Ganzen ja...

[SeppJ]

Michael E. schrieb:

Edit: Achso, beim ersten Verarbeiten der Datei wird gespeichert, dass das ifnef ein Include Guard ist?

Was dann übrigens auch ziemlich genau das gleiche sein muss, wie pragma once beim MS-Compiler implementiert ist, bloß mit anderem (standardkonformeren ) Schlüsselwort. Der muss sich schließlich auch irgendwie merken, welche Dateien er schon hatte und ob da ein pragma once drin stand.

[dot]

#pragma once ist auch standardkonform... :p

[Gast]

Es ist kein offizieller Standard, wird sich aber kaum ein Compiler drüber beschweren. Wenn die Sache auch nicht gerade viel mehr Geschwindigkeit bringt, so kann man wenigstens auf drei Zeilen Includeguard + Namensfindung verzichten und schreibt einfach #pragma once und gut is.

[Sone]

dot schrieb:

#pragma once ist auch standardkonform... :p

N3337 16.6 schrieb:

1. A preprocessing directive of the form

# pragma pp-tokensopt new-line

causes the implementation to behave in an implementation-defined manner.[...]

[pumuckl]

Sone schrieb:

[...]

Du musst schon noch dazu sagen, was du mit dem Zitat jetzt aussagen willst. Ich vermute mal dass du behaupten willst, #pragma once wäre nicht standardkonform. Das wäre allerdings falsch gedacht, es ist standardkonform, aber eben nicht portabel

[Gast]

Naja, welcher große Compiler kann nicht damit umgehen, so dass man sagen kann es wäre nicht portabel?

[asc]

Butterbrot schrieb:

#include Guards oder #pragma once?

Ich verwende eigentlich immer ersteres, wobei ich derzeit ohnehin dazu gezwungen bin (Wenn man keine Includeguards mit exakt dem Dateinamen im C++ Builder verwendet, stellt er die Dateien nicht in Kombination dar und man kommt ggf. nur umständlich an den Inhalt).

[nman]

Butterbrot schrieb:

Naja, welcher große Compiler kann nicht damit umgehen, so dass man sagen kann es wäre nicht portabel?

Es ist nicht portabel, weil zB. der gcc damit nicht das macht, was du eigentlich machen möchtest.

Dass andere Compiler nicht crashen, deine Browser-History löschen oä. macht das Beispiel noch lange nicht portabel – es passiert ja nicht das, was du haben möchtest.

[Gast]

Der GCC inkludiert die Dateien mit #pragma once nicht nur einmal, oder wie soll ich das verstehen mit dem "Es macht nicht das was du haben willst"?

[dot]

Einfach beides verwenden, völlig standardkonform, portabel und dann gibts garantiert kein Problem...

[Sone]

pumuckl schrieb:

Sone schrieb:

[...]

Du musst schon noch dazu sagen, was du mit dem Zitat jetzt aussagen willst. Ich vermute mal dass du behaupten willst, #pragma once wäre nicht standardkonform. Das wäre allerdings falsch gedacht, es ist standardkonform, aber eben nicht portabel

Nein, es ist standardkonform - es kompiliert ja!
Es ist lediglich Implementationsspezifisch ob es ignoriert wird oder nicht.

[dot]

Sone schrieb:

Nein, es ist standardkonform - es kompiliert ja!
Es ist lediglich Implementationsspezifisch ob es ignoriert wird oder nicht.

Exakt

Und jetzt denk drüber nach, wieso man Include Guards überhaupt verwendet...

[Gast]

Da wir nun raus gefunden haben, dass #pragma once keinen großen Einfluss auf die Geschwindigkeit des Kompilierens hat(jedenfalls bei kurzen Dateien) habe ich immer noch die Frage, ob es portabel ist oder nicht?

Nman sagt nein. Ich denke ja, wenn man nur für Windows/Linux/OSX, mit den dort gängigen Compilern entwickelt.

Nicht portabel wäre es, in meinen Augen, wenn ich es nur unter einem System nutzen könnten, aber so wie ich es verstanden habe reicht mir ein #pragma once in den Header-Dateien und es erfüllt seinen Zweck auch für die großen Compilern auf den großen drei Systemen.

[Shade Of Mine]

Butterbrot schrieb:

Da wir nun raus gefunden haben, dass #pragma once keinen großen Einfluss auf die Geschwindigkeit des Kompilierens hat(jedenfalls bei kurzen Dateien) habe ich immer noch die Frage, ob es portabel ist oder nicht?

Die Frage ist doch dadurch gelöst, dass es für die Geschwindigkeit nichts bringt.
Dadurch ist klar, dass man pragma once nicht verwenden sollte.

[nman]

Butterbrot schrieb:

Nman sagt nein. Ich denke ja, wenn man nur für Windows/Linux/OSX, mit den dort gängigen Compilern entwickelt.

Weil ich nicht wusste, dass die großen Compiler mittlerweile auch tatsächlich alle das richtige machen.

Aber deine Definition von portabel ist auch interessant. Meine Programme sind alle portabel solange du auf einem 32bit WinXP SP3 entwickelst.

[Gast]

Shade Of Mine schrieb:

Butterbrot schrieb:

Da wir nun raus gefunden haben, dass #pragma once keinen großen Einfluss auf die Geschwindigkeit des Kompilierens hat(jedenfalls bei kurzen Dateien) habe ich immer noch die Frage, ob es portabel ist oder nicht?

Die Frage ist doch dadurch gelöst, dass es für die Geschwindigkeit nichts bringt.
Dadurch ist klar, dass man pragma once nicht verwenden sollte.

Das ist falsch, es erspart dir drei Zeilen überflüssigen Includeguardcode mit eventuellen Konflikten der per define gesetzten Namen, z.B durch kopierte Headedateien für die nächste Klasse etc.

#pragma once hat dadurch einfach mehr Vor- als Nachteile.

nman schrieb:

Aber deine Definition von portabel ist auch interessant. Meine Programme sind alle portabel solange du auf einem 32bit WinXP SP3 entwickelst.

Wo habe ich das geschrieben? Wieso kann ich nicht unter Windows portable Anwendungen entwickeln?

[Jonas OSDever]

Butterbrot schrieb:

Shade Of Mine schrieb:

Butterbrot schrieb:

Da wir nun raus gefunden haben, dass #pragma once keinen großen Einfluss auf die Geschwindigkeit des Kompilierens hat(jedenfalls bei kurzen Dateien) habe ich immer noch die Frage, ob es portabel ist oder nicht?

Die Frage ist doch dadurch gelöst, dass es für die Geschwindigkeit nichts bringt.
Dadurch ist klar, dass man pragma once nicht verwenden sollte.

Das ist falsch, es erspart dir drei Zeilen überflüssigen Includeguardcode mit eventuellen Konflikten der per define gesetzten Namen, z.B durch kopierte Headedateien für die nächste Klasse etc.

#pragma once hat dadurch einfach mehr Vor- als Nachteile.

Also ist es bei dir moeglich, dass es einen Konflikt bei

#define XXX_HEADER_INCLUDED__

gibt? Dann wuerde ich meinen Coding-Stil eindeutig mal ueberdenken... Ausserdem, wieso kopierst du Header-Dateien fuer die naechste Klasse? VS generiert sowieso schon Ctor und Dtor automatisch, weshalb du Klassen eh nicht so einfach kopieren kannst. Und wenn du die Eigenschaften einer anderen Klasse brauchst, dann erbe halt von ihr oder benutz sie per Komposition. Ich sehe irgendwie den Sinn hinter kompletten Header-Copy&Paste nicht. Und solltest du das wirklich kopieren wollen ist es nicht soo viel schwerer, wenn du Implementierung und Deklaration trennst, nur die Klasse zu markieren.

Und auf die 3 Zeilen kommts nun wirklich nicht an. Ich muss sie nicht mal selber schreiben, macht schon VAX, wenn ich ihn bitte.

Butterbrot schrieb:

nman schrieb:

Aber deine Definition von portabel ist auch interessant. Meine Programme sind alle portabel solange du auf einem 32bit WinXP SP3 entwickelst.

Wo habe ich das geschrieben? Wieso kann ich nicht unter Windows portable Anwendungen entwickeln?

Portabel heisst, dass die Anwendung so ohne Veraenderung auf allen Systemen mit jedem Standard-konformen Compiler kompiliert werden koennte. #pragma darf zwar keinen Fehler schmeissen, wenn der Compiler die Dierektive dahinter nicht kennt, aber trotzdem ist der Include-Guard-Effekt dahin. Und dann kommen die Neudeklarationen von den Typen. Boom, Compiler-Fehler.
Natuerlich kann man nicht jede Software portabel gestalten, schon allein dadurch, dass der Standard keine GUI-Sachen, noch keine Filesystemunterstuetzung etc. hat. Aber wenn schon die Header nicht zwangslaeufig funktionieren, dann gute Nacht beim portieren.

Es spricht ja nichts dagegen, #pragma once zu verwenden - aber dann in Verbindung mit einem Include-Guard. So kann der Compiler, sofern er es unterstuetzt, die Kompilierung an der Stelle abbrechen und fuer die, die es nicht unterstuetzen hast du trotzdem noch einen Include-Guard.

[Gast]

Ich gebe dir ja recht, dass es selten vorkommt, dass man die gleichen #defines nimmt. Wie wohl auch so viele Feinheiten von C++ selten zum tragen kommen und trotzdem bis aufs Erbrechen verteidigt werden. Warum einmal Hü und einmal Hott?

Mit welchen Compilern funktioniert denn das #pragma once nicht wie es soll, die bei Windows, Linux und OSX nicht auf häufigsten eingesetzt werden?

Denn wenn was auf diesen Systemen läuft, nenne ICH das portabel. Wenn man es nicht portable nennt, dann sind Qt und wxWidgets etc. auch nicht portabel.

Wäre nett wenn wir hier mal zum Schluß kommen, ich will eigentlich coden und nicht in einem Forum rumposten. Wenn wie gesagt es nicht portabel läuft(Windows/Linux/OSX mit gängigen Compilern) dann mache ich doch beides, also pragma und guard. Wenn ich mir aber getrost jedes mal die drei Zeilen sparen kann, dann lasse ich es. Noch bin ich am Anfang meines Projektes, aber die Klassen werden von Tag zu Tag mehr und ich will da schon konsistent bleiben. Damit man zur Not mal vielleicht ein "sed script"/"Replace in Files" drüber jagen kann.

[dot]

Warum die ganze Diskussion!? Verwendet einfach beides und die Sache ist erledigt...

Jonas OSDever schrieb:

#define XXX_HEADER_INCLUDED__

Kleiner Hinweis dazu: Wenn du deine Include Guards so benennst, ist dein Programm streng genommen UB. Laut Standard sind alle Namen, die einen doppelten Underscore beinhalten für den Compiler reserviert. In der Praxis wirst du damit kaum Probleme haben, aber ich würd mir einfach eine bessere Namenskonvention ausdenken...