我正在开发一个已知只能在 Windows 上运行并在 Visual Studio 下编译的代码库（它与 excel 紧密集成，所以它不会去任何地方）。我想知道我是否应该使用传统的包含守卫或使用#pragma once 作为我们的代码。我认为让编译器处理#pragma once 会产生更快的编译速度，并且在复制和粘贴时更不容易出错。它也稍微不那么难看;)
注意：为了获得更快的编译时间，我们可以使用Redundant Include Guards，但这会增加包含文件和包含文件之间的紧密耦合。通常没关系，因为防护应该基于文件名，并且只有在您需要更改包含名称时才会更改。
【问题讨论】：
标签： c++ coding-style
我认为它不会对编译时间产生显着影响，但 #pragma once 在编译器中得到了很好的支持，但实际上并不是标准的一部分。预处理器可能会更快一些，因为它更容易理解您的确切意图。
#pragma once 更不容易出错，输入的代码也更少。
要加快编译时间，只需转发声明而不是尽可能包含在 .h 文件中。
我更喜欢使用#pragma once。
【讨论】：
#pragma once 不可靠（不同的文件层次结构视角（当前工作目录）、软链接和硬链接、网络文件系统，甚至名称冲突——尝试使用名为 string.h 的文件或类似的东西--)。在不考虑速度的情况下，您可以使用一个脚本来替换文件中的任何 %INCLUDE_GUARD% 来替换自动管理的保护符号；您可以将标头编写为@987654328@，并且由于您已经拥有预处理器条件对，因此最终标头不会流动，并且编译器会在诊断中发出正确的行号。
#pragma once 所谓的可靠性问题。如果我有两个不同的标题foo/string.h 和bar/string.h，那么放置#pragma once 意味着我可以将它们中的每一个都包含一次，但同时包含它们也可以。如果我使用包含保护，那么我可能会在两个文件中写入类似#ifndef STRING_H 的内容 - 这意味着我不能同时包含 foo/string.h 和 bar/string.h。
string.h，那么如果你还没有使用命名空间，那么你可能最终会出现内部名称冲突，因为两个具有该名称的文件都可能做一些涉及字符串的事情，如果你使用命名空间，在我看来，你应该在包含保护标识符中包含命名空间。
我只是想在这个讨论中补充一点，我只是在 VS 和 GCC 上编译，并且曾经使用包含保护。我现在已经切换到#pragma once，对我来说唯一的原因不是性能、可移植性或标准，因为只要 VS 和 GCC 支持它，我真的不在乎什么是标准，那就是：
#pragma once 减少了出现错误的可能性。
很容易将一个头文件复制并粘贴到另一个头文件，修改它以适应自己的需要，而忘记更改包含保护的名称。两者都包含后，您需要一段时间才能找到错误，因为错误消息不一定清楚。
【讨论】：
#pragma once，因为它更不容易出错。我突然想到，如果编译器已经在跟踪包含守卫，那么当他们看到使用相同宏名称的不同文件时，他们已经做了大部分必要的工作来发出警告。
#pragma once 有无法修复的错误。永远不要使用它。如果您的#include 搜索路径足够复杂，编译器可能无法区分具有相同基本名称的两个标头（例如a/foo.h 和b/foo.h），因此其中一个标头中有#pragma once将抑制 both。它也可能无法分辨出两个不同的相对包含（例如，#include "foo.h" 和 #include "../a/foo.h" 指的是同一个文件，因此 #pragma once 将无法在应该包含冗余包含时抑制它。
这也会影响编译器避免使用#ifndef 保护重读文件的能力，但这只是一种优化。使用#ifndef 保护，编译器可以安全地读取任何它确定它已经看到的文件；如果它是错误的，它只需要做一些额外的工作。只要没有两个头文件定义相同的保护宏，代码就会按预期编译。如果两个头文件确实定义了相同的保护宏，程序员可以进去修改其中一个。
#pragma once 没有这样的安全网——如果编译器对头文件的标识有误，无论哪种方式，程序都将无法编译。如果您遇到此错误，您唯一的选择是停止使用#pragma once，或重命名其中一个标题。标头的名称是您的 API 合同的一部分，因此重命名可能不是一种选择。
（为什么这是不可修复的简短版本是，Unix 和 Windows 文件系统 API 都没有提供任何机制来保证告诉您两个绝对路径名是否引用同一个文件。如果您认为可以使用 inode 编号，对不起，您错了。）
（历史记录：大约 12 年前，当我有权这样做时，我没有将 #pragma once 和 #import 从 GCC 中删除的唯一原因是 Apple 的系统头文件依赖于它们。回想起来，这不应该阻止我。）
（因为这在评论线程中出现了两次：GCC 开发人员确实付出了相当多的努力来使#pragma once 尽可能可靠；请参阅GCC bug report 11569。但是，当前版本的 GCC 中的实现在合理的情况下仍然可能失败，例如构建农场遭受时钟偏差。我不知道任何其他编译器的实现是什么样的，但我不希望有人做得更好 em>.)
【讨论】：
#pragma once 来解决。
#pragma once :) 再次，必须为那个 pragma 定义某种理智的语义。如果您想多次包含相同的内容，请不要将#pragma once 放在里面:)
直到#pragma once 成为标准的那一天（这目前不是未来标准的优先事项），我建议你使用它并使用守卫，这样：
#ifndef BLAH_H
#define BLAH_H
#pragma once
// ...
#endif
原因是：
#pragma once 不是标准的，因此某些编译器可能不提供该功能。也就是说，所有主要编译器都支持它。如果编译器不知道它，至少它会被忽略。#pragma once 没有标准行为，您不应假设所有编译器的行为都相同。守卫将至少确保基本假设对于至少为守卫实现所需预处理器指令的所有编译器都是相同的。#pragma once 将加快编译（一个 cpp），因为编译器不会重新打开包含该指令的文件。因此，将它放在文件中可能会有所帮助，也可能没有帮助，具体取决于编译器。我听说 g++ 可以在检测到警卫时进行相同的优化，但必须确认。将两者结合使用，您可以充分利用每个编译器。
现在，如果您没有一些自动脚本来生成守卫，使用#pragma once 可能更方便。只知道这对可移植代码意味着什么。 （我正在使用 VAssistX 快速生成守卫和 pragma 一次）
您几乎应该始终以可移植的方式考虑您的代码（因为您不知道未来是由什么组成的），但如果您真的认为它不应该使用另一个编译器进行编译（用于非常特定的嵌入式硬件的代码例如）那么您应该只检查有关#pragma once 的编译器文档以了解您真正在做什么。
【讨论】：
#pragma once 比包含保护更短，更不容易出错，大多数编译器都支持它，而且有人说它编译得更快（这不是真的[不再]）。
但我仍然建议您使用标准的 #ifndef 包括警卫。
#ifndef？考虑这样一个人为的类层次结构，其中每个类 A、B 和 C 都位于自己的文件中：
#ifndef A_H
#define A_H
class A {
public:
// some virtual functions
};
#endif
#ifndef B_H
#define B_H
#include "a.h"
class B : public A {
public:
// some functions
};
#endif
#ifndef C_H
#define C_H
#include "b.h"
class C : public B {
public:
// some functions
};
#endif
现在假设您正在为您的类编写测试，并且您需要模拟真正复杂的类B 的行为。一种方法是使用例如google mock 编写mock class 并将其放在目录mocks/b.h 中。请注意，类名没有改变，只是存储在不同的目录中。但最重要的是包含保护的名称与原始文件 b.h 中的名称完全相同。
#ifndef B_H
#define B_H
#include "a.h"
#include "gmock/gmock.h"
class B : public A {
public:
// some mocks functions
MOCK_METHOD0(SomeMethod, void());
};
#endif
使用这种方法，您可以模拟类B 的行为，而无需触及原始类或告诉C。您所要做的就是将目录mocks/ 放入编译器的包含路径中。
#pragma once 完成？如果您使用 #pragma once，您会遇到名称冲突，因为它无法保护您避免定义类 B 两次，一次是原始版本，一次是模拟版本。
【讨论】：
b.h 和模拟 b.h 都在编译器中包含路径 - 会不会与 #include "b.h" 发生名称冲突？如果您从测试项目的包含目录中删除原始b.h 路径，以便只拾取模拟b.h，那么#pragma once 是否也可以工作？
mocks/b.h 添加到包含路径，您还应该删除原始的 b.h 而不是依赖包含保护。您的解决方案与符号插入一样蹩脚：-/
如果您确定永远不会在不支持它的编译器中使用此代码（Windows/VS、GCC 和 Clang 是 支持它的编译器示例），那么您当然可以毫无顾虑地使用#pragma 一次。
您也可以同时使用两者（参见下面的示例），以便在兼容系统上获得可移植性和编译速度
#pragma once
#ifndef _HEADER_H_
#define _HEADER_H_
...
#endif
【讨论】：
在就#pragma once 和#ifndef 守卫之间假定的性能权衡与正确与否的论点进行了扩展讨论之后（基于最近的一些灌输，我站在#pragma once 一边)，我决定最终测试#pragma once 更快的理论，因为编译器不必尝试重新#include 已包含的文件。
为了测试，我自动生成了 500 个具有复杂相互依赖关系的头文件，并有一个 .c 文件，其中 #includes 全部。我以三种方式运行测试，一次只使用#ifndef，一次使用#pragma once，一次使用两者。我在一个相当现代的系统上进行了测试（运行 OSX 的 2014 MacBook Pro，使用 XCode 捆绑的 Clang，带有内部 SSD）。
一、测试代码：
#include <stdio.h>
//#define IFNDEF_GUARD
//#define PRAGMA_ONCE
int main(void)
{
int i, j;
FILE* fp;
for (i = 0; i < 500; i++) {
char fname[100];
snprintf(fname, 100, "include%d.h", i);
fp = fopen(fname, "w");
#ifdef IFNDEF_GUARD
fprintf(fp, "#ifndef _INCLUDE%d_H\n#define _INCLUDE%d_H\n", i, i);
#endif
#ifdef PRAGMA_ONCE
fprintf(fp, "#pragma once\n");
#endif
for (j = 0; j < i; j++) {
fprintf(fp, "#include \"include%d.h\"\n", j);
}
fprintf(fp, "int foo%d(void) { return %d; }\n", i, i);
#ifdef IFNDEF_GUARD
fprintf(fp, "#endif\n");
#endif
fclose(fp);
}
fp = fopen("main.c", "w");
for (int i = 0; i < 100; i++) {
fprintf(fp, "#include \"include%d.h\"\n", i);
}
fprintf(fp, "int main(void){int n;");
for (int i = 0; i < 100; i++) {
fprintf(fp, "n += foo%d();\n", i);
}
fprintf(fp, "return n;}");
fclose(fp);
return 0;
}
现在，我的各种测试运行：
folio[~/Desktop/pragma] fluffy$ gcc pragma.c -DIFNDEF_GUARD
folio[~/Desktop/pragma] fluffy$ ./a.out
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.164s
user 0m0.105s
sys 0m0.041s
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.140s
user 0m0.097s
sys 0m0.018s
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.193s
user 0m0.143s
sys 0m0.024s
folio[~/Desktop/pragma] fluffy$ gcc pragma.c -DPRAGMA_ONCE
folio[~/Desktop/pragma] fluffy$ ./a.out
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.153s
user 0m0.101s
sys 0m0.031s
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.170s
user 0m0.109s
sys 0m0.033s
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.155s
user 0m0.105s
sys 0m0.027s
folio[~/Desktop/pragma] fluffy$ gcc pragma.c -DPRAGMA_ONCE -DIFNDEF_GUARD
folio[~/Desktop/pragma] fluffy$ ./a.out
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.153s
user 0m0.101s
sys 0m0.027s
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.181s
user 0m0.133s
sys 0m0.020s
folio[~/Desktop/pragma] fluffy$ time gcc -E main.c > /dev/null
real 0m0.167s
user 0m0.119s
sys 0m0.021s
folio[~/Desktop/pragma] fluffy$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin17.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
如您所见，带有#pragma once 的版本的预处理速度确实比#ifndef 稍快——只有一个，但是差异可以忽略不计，并且会被实际构建和链接代码所需的时间。也许如果代码库足够大，它实际上可能会导致构建时间的差异只有几秒钟，但是现代编译器能够优化#ifndef 守卫，操作系统具有良好的磁盘缓存这一事实，以及存储技术速度的提高，似乎性能论点是没有实际意义的，至少在当今时代的典型开发人员系统上是这样。较旧且更具异国情调的构建环境（例如，托管在网络共享上的标头，从磁带构建等）可能会在一定程度上改变等式，但在这些情况下，首先简单地创建一个不那么脆弱的构建环境似乎更有用。
事实上，#ifndef 是标准化的标准行为，而#pragma once 不是，#ifndef 也处理奇怪的文件系统和搜索路径的极端情况，而#pragma once 可能会被某些事情搞糊涂，导致程序员无法控制的错误行为。 #ifndef 的主要问题是程序员为他们的守卫选择了不好的名字（名称冲突等），即使这样，API 的使用者也很有可能使用 #undef 覆盖那些不好的名字 - 这不是一个完美的解决方案，也许吧，但它可能，而如果编译器错误地剔除#include，#pragma once 就没有办法了。
因此，尽管 #pragma once 明显（略）快，但我不同意这本身就是使用它而不是 #ifndef 守卫的理由。
编辑：感谢@LightnessRacesInOrbit 的反馈，我增加了头文件的数量并将测试更改为仅运行预处理器步骤，从而消除了由编译和链接过程（以前很简单，现在不存在）。正如预期的那样，差异大致相同。
【讨论】：
我通常不会为#pragma once 烦恼，因为我的代码有时必须使用 MSVC 或 GCC 以外的东西进行编译（嵌入式系统的编译器并不总是有 #pragma）。
所以无论如何我都必须使用#include 守卫。正如一些答案所建议的那样，我也可以使用#pragma once，但似乎没有太多理由，而且它通常会在不支持它的编译器上引起不必要的警告。
我不确定 pragma 可以节省多少时间。我听说编译器通常已经识别出头文件何时只有保护宏之外的 cmets 并且在这种情况下将执行 #pragma once 等效项（即，不再处理文件）。但我不确定这是真的还是编译器的一个例子可以做这个优化。
在任何一种情况下，我都可以更轻松地使用 #include 保护，它可以在任何地方工作，而不必再担心它。
【讨论】：
有一个related question，I answered：
#pragma once确实有一个缺点（除了非标准），那就是如果你在不同的位置有相同的文件（我们有这个，因为我们的构建系统复制文件）然后编译器会认为这些是不同的文件。
我也在此处添加答案，以防有人偶然发现这个问题而不是其他问题。
【讨论】：
#pragma once 实现，它应该使用可靠的校验和而不是粗略的文件名。
我认为您应该做的第一件事是检查这是否真的会有所作为，即。您应该首先测试性能。谷歌中的一项搜索抛出了this。
在结果页面中，这些列对我来说有点偏离，但很明显，至少在 VC6 之前，微软没有实现其他工具正在使用的包含保护优化。与包含防护在外部的情况相比，包含防护在内部的时间是外部防护的 50 倍（外部包含防护至少与#pragma 一样好）。但让我们考虑一下这可能产生的影响：
根据提供的表格，打开包含并检查它的时间是 #pragma 等效项的 50 倍。但在 1999 年，实际执行此操作的时间为每个文件 1 微秒！
那么，一个 TU 会有多少个重复的标头？这取决于您的风格，但如果我们说平均 TU 有 100 个重复项，那么在 1999 年我们可能会为每个 TU 支付 100 微秒。随着 HDD 的改进，现在这可能会显着降低，但即使这样，使用预编译的头文件和正确的依赖项跟踪项目的总累积成本几乎肯定是构建时间的一个微不足道的部分。
现在，另一方面，如果您改用不支持 #pragma once 的编译器，那么这可能不太可能，那么请考虑更新整个源代码库以包含保护需要多长时间而不是#pragma？
微软没有理由不能像 GCC 和所有其他编译器那样实现包含保护优化（实际上任何人都可以确认他们的最新版本是否实现了这一点？）。恕我直言，#pragma once 除了限制您对替代编译器的选择之外几乎没有什么作用。
【讨论】：
#pragma once 允许编译器在文件再次出现时完全跳过文件 - 而不是在文件到达#include 保护之前解析文件。
因此，语义略有不同，但如果按照它们的预期使用方式使用它们，它们是相同的。
将两者结合起来可能是最安全的方法，因为在最坏的情况下（编译器将未知的编译指示标记为实际错误，而不仅仅是警告），您只需要自己删除 #pragma 即可。
当您将平台限制为“桌面上的主流编译器”时，您可以放心地省略 #include 保护，但我也对此感到不安。
OT：如果您有其他关于加快构建的技巧/经验可以分享，我会很好奇。
【讨论】：
对于那些想使用 #pragma once 并同时包含守卫的人：如果您不使用 MSVC，那么您将不会从 #pragma once 获得太多优化。
并且您不应该将“#pragma once”放入应该包含多次的标题中，每次包含可能具有不同的效果。
Here 是关于#pragma once 用法的详细讨论。
【讨论】：
#pragma once放到一个应该被多次包含的头文件中。” -- 它适用于被多次包含的头文件；这就是重点。我认为你的意思是它不应该用于应该被多次包含的标题每个包含可能具有不同的效果。这方面的例子很少； <assert.h> 或 <cassert> 就是这样一个例子（因为它的行为取决于是否定义了 NDEBUG）。
上面Konrad Kleine的解释。
简要总结：
# pragma once 时，这是编译器的大部分责任，不允许多次包含它。这意味着，在您在文件中提到 code-sn-p 之后，您就不再需要负责了。现在，编译器在文件开头查找此代码-sn-p，并跳过它被包含（如果已经包含一次）。这肯定会减少编译时间（平均而言，在巨大的系统中）。但是，在模拟/测试环境中，由于循环等依赖，会使测试用例的实现变得困难。
#ifndef XYZ_H 用于标头时，开发人员有更多的责任来维护标头的依赖关系。这意味着，每当由于一些新的头文件，存在循环依赖的可能性时，编译器只会在编译时标记一些“undefined ..”错误消息，由用户检查实体的逻辑连接/流和纠正不正确的包含。这肯定会增加编译时间（需要纠正并重新运行）。此外，由于它是在包含文件的基础上工作的，基于“XYZ_H”定义状态，并且如果无法获得所有定义，仍然会抱怨。
因此，为了避免这种情况，我们应该使用 as;
#pragma once
#ifndef XYZ_H
#define XYZ_H
...
#endif
即两者的结合。
【讨论】：