#pragma once vs include guards? #pragma einmal gegen Include-Guards?

Question

Ich arbeite an einer Codebasis, die nur unter Windows ausgeführt und unter Visual Studio kompiliert werden kann (sie integriert sich eng mit Excel, daher bleibt sie bestehen). Ich frage mich, ob ich mich für die traditionellen Include-Wächter entscheiden sollte oder #pragma once für unseren Code verwenden soll. Ich denke, dass es schneller zu kompilieren ist und weniger fehleranfällig ist, wenn man den Compiler #pragma once behandeln lässt. Außerdem ist es etwas weniger hässlich ;)

Hinweis: Um schnellere Kompilierzeiten zu erreichen, könnten wir Redundante Include-Wächter verwenden, aber das führt zu einer engen Kopplung zwischen der eingebundenen Datei und der einbindenden Datei. Normalerweise ist das in Ordnung, da der Wächter auf dem Dateinamen basieren sollte und nur geändert werden würde, wenn Sie den Include-Namen ohnehin ändern müssten.

Answer 1

Ich glaube nicht, dass es einen signifikanten Unterschied in der Kompilierungszeit machen wird, aber #pragma once wird von den meisten Compilern sehr gut unterstützt, ist jedoch nicht Teil des Standards. Der Präprozessor kann mit ihm etwas schneller sein, da er einfacher zu verstehen ist und Ihre genaue Absicht klarer ist.

#pragma once ist weniger fehleranfällig und erfordert weniger Codeeingabe.

Um die Kompilierungszeit weiter zu verkürzen, deklarieren Sie einfach vorwärts anstatt in .h-Dateien einzufügen, wenn es möglich ist.

Ich ziehe es vor, #pragma once zu verwenden.

Siehe diesen Wikipedia-Artikel über die Möglichkeit, beide zu verwenden.

Answer 2

Bis zum Tag, an dem #pragma once Standard wird (das ist derzeit keine Priorität für die zukünftigen Standards), schlage ich vor, dass Sie es verwenden UND Wachen einsetzen, auf diese Weise:

#ifndef BLAH_H
#define BLAH_H
#pragma once

// ...

#endif

Die Gründe dafür sind:

• #pragma once ist nicht standardmäßig, daher ist es möglich, dass einige Compiler die Funktionalität nicht bereitstellen. Alle großen Compiler unterstützen es jedoch. Wenn ein Compiler es nicht kennt, wird es zumindest ignoriert.
• Da es kein Standardverhalten für #pragma once gibt, sollten Sie nicht davon ausgehen, dass das Verhalten auf allen Compilern gleich sein wird. Die Wachen stellen sicher, dass zumindest die grundlegende Annahme für alle Compiler gleich ist, die die erforderlichen Präprozessoranweisungen für Wachen implementieren.
• Auf den meisten Compilern wird die Kompilierung (einer cpp) durch #pragma once beschleunigt, da der Compiler die Datei, die diese Anweisung enthält, nicht erneut öffnet. Es kann helfen, dies in einer Datei zu haben, oder auch nicht, abhängig vom Compiler. Ich habe gehört, dass g++ die gleiche Optimierung durchführen kann, wenn Wachen erkannt werden, aber das muss bestätigt werden.

Wenn Sie beides zusammen verwenden, erhalten Sie das Beste von jedem Compiler dafür.

Wenn Sie keine automatischen Skripte haben, um die Wachen zu generieren, ist es möglicherweise bequemer, einfach #pragma once zu verwenden. Wissen Sie jedoch, was das für portablen Code bedeutet. (Ich verwende VAssistX, um schnell die Wachen und pragma once zu generieren)

Sie sollten fast immer über Ihren Code in portabler Weise nachdenken (weil Sie nicht wissen, woraus die Zukunft besteht), aber wenn Sie wirklich glauben, dass er nicht mit einem anderen Compiler kompiliert werden soll (wie Code für sehr spezifische eingebettete Hardware zum Beispiel), sollten Sie einfach die Dokumentation Ihres Compilers zu #pragma once überprüfen, um zu wissen, was Sie wirklich tun.

Answer 3

Aus der Perspektive eines Software-Testers

#pragma once ist kürzer als ein Include-Wächter, weniger fehleranfällig, von den meisten Compilern unterstützt, und einige behaupten, dass es schneller kompiliert (was nicht mehr wahr ist).

Aber ich schlage immer noch vor, standardmäßige #ifndef Include-Wächter zu verwenden.

Warum #ifndef?

Betrachten Sie eine konstruierte Klassenhierarchie wie diese, in der jede der Klassen A, B und C in ihrer eigenen Datei lebt:

a.h

#ifndef A_H
#define A_H

class A {
public:
  // einige virtuelle Funktionen
};

#endif

b.h

#ifndef B_H
#define B_H

#include "a.h"

class B : public A {
public:
  // einige Funktionen
};

#endif

c.h

#ifndef C_H
#define C_H

#include "b.h"

class C : public B {
public:
  // einige Funktionen
};

#endif

Angenommen, Sie schreiben Tests für Ihre Klassen und müssen das Verhalten der wirklich komplexen Klasse B simulieren. Eine Möglichkeit dies zu tun wäre, eine Mock-Klasse zu schreiben, z. B. mit Google Mock und sie in einem Verzeichnis mocks/b.h abzulegen. Beachten Sie, dass der Klassenname unverändert bleibt, er wird nur in einem anderen Verzeichnis gespeichert. Aber am wichtigsten ist, dass der Include-Wächter genau den gleichen Namen hat wie in der Originaldatei b.h.

mocks/b.h

#ifndef B_H
#define B_H

#include "a.h"
#include "gmock/gmock.h"

class B : public A {
public:
  // einige Mock-Funktionen
  MOCK_METHOD0(SomeMethod, void());
};

#endif

Was ist der Nutzen?

Mit diesem Ansatz können Sie das Verhalten der Klasse B ohne Änderungen an der Originalklasse oder deren Verwendung in C verändern. Alles was Sie tun müssen, ist das Verzeichnis mocks/ in den Include-Pfad Ihres Compilers einzufügen.

Warum funktioniert dies nicht mit #pragma once?

Wenn Sie #pragma once verwendet hätten, käme es zu einem Namenskonflikt, da es Sie nicht davor schützen kann, die Klasse B zweimal zu definieren, einmal die Originale und einmal die gemockte Version.

Answer 4

Wenn Sie sicher sind, dass Sie diesen Code niemals in einem Compiler verwenden werden, der ihn nicht unterstützt (Windows/VS, GCC und Clang sind Beispiele für Compiler, die es unterstützen), können Sie #pragma once ohne Bedenken verwenden.

Sie können auch einfach beide verwenden (siehe Beispiel unten), um Portabilität und Kompilierungsgeschwindigkeit auf kompatiblen Systemen zu erhalten

#pragma once
#ifndef _HEADER_H_
#define _HEADER_H_

...

#endif

Answer 5

Es gibt eine verwandte Frage, zu der ich geantwortet habe:

#pragma once hat einen Nachteil (abgesehen davon, dass es nicht standardmäßig ist) und das ist, wenn Sie die gleiche Datei an verschiedenen Orten haben (wir haben das, weil unser Build-System Dateien kopiert), dann wird der Compiler denken, dass dies verschiedene Dateien sind.

Ich füge die Antwort hier auch hinzu, falls jemand über diese Frage stolpert und nicht über die andere.