4. #include Guard vs #pragma once

#include Guard vs #pragma once

  • J

    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.

    0
  • ?

    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.

    0

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

    0
  • Mod

    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.

    0
  • K

    Ich steh nicht so auf Warnungen, daher ifdef.

    0
  • ?

    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?

    0

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

    0
  • J

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

    0

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

    0
  • ?

    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?

    0

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

    0
  • ?

    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.

    0

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

    0
  • ?

    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.

    0

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

    0
  • ?

    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.

    0

  • Du kannst doch einfach beim VS die Tastaturbelegung ändern (Tools/Customize -> Keyboard).

    0
  • ?

    Es gibt schlicht weg keinen Toggle für Kommentare oder Header/Source-Switch. Da es diese Funktionen nicht gibt, kann ich sie auch keiner Taste zuweisen. Dieses "gehe zur Definition" etc. oder zwei verschiedene Funktionen für Kommentar setzten und entfernen ist wirklich ziemlich umständlich, wenn man es einmal anders gesehen hat.

    Beim Creator drückst du einfach eine Taste und guckst damit kurz in den Header oder Source, je nach dem wo du gerade bist und mit der gleichen Taste, ohne neu auf der Tastatur suchen zu müssen oder gar zur Maus zu wechseln, kommst du wieder zurück. Genauso ist es mit dem Kommentieren und Auskommentieren.

    Ich habe mir jetzt mal Codelite angeschaut, da ist es auch gleich out-of-the-box also zusammen:
    - Kommentar Toggle
    - Header/Source Toggle
    - Git
    - Doxygen
    - Snippets
    - Plugins
    - easy Vorlagen-/Templateerstellung
    - Refaktoring
    Alles da und dazu noch kostenlos, was will man mehr. Für Standardgeschichten muss man VS mit Plugins zuschütten die teilweise nicht mal kostenlos sind, einiger der Features bringt z.b Visual-Assist und jetzt ist mir auch klar warum das so beliebt.

    Das Kommentar-Toggle hat übrigens Eclipse auch, ist also wirklich eine Art Standard.

    Vielleicht bleibe ich sogar bei Codelite mit wxWidgets, mal schauen. Man hat ja Zeit und kann viel rumprobieren und sich in Ruhe dann für das Beste entscheiden.

    0
  • ?

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

    Ist ja jetzt nicht so schwer über alle Header-Dateien zu iterieren, das #pragma once durch #ifndef...\n#define zu ersetzen und hinter die letzte Zeile noch ein #endif zu hängen.

    0
  • O

    dot schrieb:

    [...] aber Kommentar Toggle (Text Editor Toolbar, Ctrl + K + C/ Ctrl + K + U)[...]

    Es ist aber umständlich und schlecht gelöst. Ich benutze einen echt einfachen Texteditor (scite) und der hat den besten Kommentartoggle den ich jemals gesehen hab (bis auf die standardtastenbelegung...lol):

    strg+Q(!!!) erzeugt, sofern es nicht vorhanden ist, als kommntar so etwas wie //~ und ein erneuter Tastendruck entfernt es. Auf diese Artt kann man nicht ausversehen Kommentare entfernen, weil die keine Tilde haben. Das heißt wenn man sowas hat:

    //kommentar
code
code

    macht ein Toggle daraus:

    //~//kommentar
//~code
//~code

    und nicht

    kommentar
//code
//code

    wie bei anderen IDEs mit Toggle. Das Empfinde ich schon als maximal hübsch.
    //edit und im Vergleich zum VC mit den zwei umständlichen Tastenkombinationen, kann man bei einem toggle nicht add und remove verwechseln.

    0
Anmelden zum Antworten