#include Guard vs #pragma once

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.

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.

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...

SeppJ

dot schrieb:

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

Wie man sieht ist das sehr Microsoft spezifisch. Beim GCC war es viel schneller, wenn man pragma once nicht benutzt. Also kann man argumentieren, man solle nur ifdef benutzen.

Kellerautomat

Ich steh nicht so auf Warnungen, daher ifdef.

Kann denn keiner hier eine klare Antwort geben, ich mache das nur als Hobby und habe mir warum auch immer leider eine klare Antwort erhofft?

Um Speed geht es schon lange nicht mehr, sondern nur darum sich immer diese drei Zeilen zu sparen, auch wenn man portabel sein will im Sinne Windows/Linux und OSX.

Macht #pragma once unter den gängigen Compiler(VC++, GCC) für Window/Linux/OSX das gleiche, also verhindert es dass diese Datei mehr als einmal genutzt wird?

Ja/Nein?

dot

Ja

Nur wenn du deinen Code dann mal mit einem Compiler kompilieren willst, der #pragma once nicht unterstützt, wirst du dir wünschen, dass du dir die zwei Zeilen damals nicht gespart hättest...

Jonas OSDever

dot schrieb:

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...

Ich dachte nur, wenn am Anfang ein oder zwei Underscores am Anfang
Ok, VAX-Snippet wird geaendert (ich hab zwar zusaetzlich noch #pragma once davor gepflanzt, aber der Doppel-Underscore war glaub ich schon Default bei VAX).

dot

Jonas OSDever schrieb:

dot schrieb:
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...
Ich dachte nur, wenn am Anfang ein oder zwei Underscores am Anfang
Ok, VAX-Snippet wird geaendert (ich hab zwar zusaetzlich noch #pragma once davor gepflanzt, aber der Doppel-Underscore war glaub ich schon Default bei VAX).

Jo, sowas mit double Underscores machen offenbar viele IDEs per default, es ist dennoch nicht standardkonform. Hier der entsprechende Abschnitt:

ISO/IEC 14882:2011 §17.6.4.3.2/1 schrieb:

Certain sets of names and function signatures are always reserved to the implementation:

Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Konservative Faustregel: Keine doppelten Underscores und keine Underscores am Anfang und du bist safe...

dot schrieb:

Ja

Nur wenn du deinen Code dann mal mit einem Compiler kompilieren willst, der #pragma once nicht unterstützt, wirst du dir wünschen, dass du dir die zwei Zeilen damals nicht gespart hättest...

Ja, klar. Ist denn abzusehen dass in den nächsten Jahren da was kommen wird? Ihr kennt euch doch sicher aus und wisst ob da irgendwo heftig geackert wird. Son Compiler in der Größenordung VC,GCC schüttelt man bestimmt nicht mal überraschend aus dem Ärmel und wenn wie groß ist dann die Wahrscheinlichkeit dass man dann noch #pragma once nicht mit einbaut?

dot

clang wird kommen bzw. ist schon da und der unterstützt #pragma once auch. Die Frage ist, ob du eben wirklich jemals und für alle Zeit nur auf den 3-4 großen Compilern laufen musst...

Ja hast recht meine Software wird mal so toll, dass ich sie in Jahren noch weiter pflegen werde und ich sie daher auch für die nächsten großen Compilern kompatibel halten muss.^^ Mit dem Gedanken werden ich nun deine Include-Methode verwenden und später in einem Interview sie als dot-Methode positiv erwähnen^^

Na dann werde ich mal wieder was schaffen, so viel habe ich heute noch nicht abgehakt.

Danke euch allen für die Kommentare und verzeiht mir meine absichtlich provokanten Fragen und Antworten.

dot

Ich sag ja nur, was kostet es schon, drei Zeilen mehr zu schreiben!?

Wenn ich z.B. MSVC spezifischen Code hab, verwend ich persönlich auch manchmal einfach nur #pragma once. Wenn ich Code hab, der portabel sein soll, dann verwend ich eben beides. Wenn es dir so sehr auf die beim Tippen vergeudete Zeit ankommt, dann überleg mal, wie viele Include Guards du in der Zeit, die du hier rumdiskutiert und auf Antworten gewartet hast, hättest tippen können...

Ist ja richtig, nur warte ich hier nun nicht unbedingt auf die Antworten, da habe ich besseres zu tun^^

Im Moment ärgere ich mich immer mehr über die Visual Studio IDE, kein Header/Source Switch, kein Kommentar-toggle und einige andere Sachen. Das kann der Qt-Creator wesentlich besser, den habe ich nämlich gerade mal getestet und das ist ja ein Traum im Vergleich zu VisualStudio.

Eine Lib unterstützt leider DirectX welches nicht von den MinGW directx headern unterstützt wird, aber dann muss kann ich erst mal auf das Standarddevice ausweichen.

dot

Butterbrot schrieb:

Im Moment ärgere ich mich immer mehr über die Visual Studio IDE, kein Header/Source Switch, kein Kommentar-toggle und einige andere Sachen.

Also ich weiß ja nicht welche Version von Visual Studio du verwendest, aber Kommentar Toggle (Text Editor Toolbar, Ctrl + K + C/ Ctrl + K + U) und Header/Source Switch (Rechtsklick im Editor) gibts in VS natürlich...

Bei einem Kommentar-Toggle drückt man immer die gleiche Taste Bsp, Ctrl+/, das geht viel schneller, genau wie beim Umschalten zwischen Header und Source mit F3. Und es ist nicht nur das, die ganze IDE ist extrem gut durchdacht. Sie musste ja auch nicht auf irgendwelche alten Versionen Rücksicht nehmen und man merkt das leider bei VS an allen Ecken. Wer einmal vom Qt-Creator( oder auch andere IDEs) mit den Features verwöhnt wurde, will nix anderes mehr^^

Aber ist wie so vieles eine Frage des Geschmacks und auch nicht Thema dieses Threads.