我希望#pragma曾经(或类似的东西)出现在标准中。包含警卫并不是什么大问题(但向学习该语言的人解释它们似乎有点困难)，但这似乎是一个可以避免的小麻烦。

事实上，因为在99.98%的情况下，#pragma once行为是理想的行为，如果编译器能自动处理防止一个头文件被多次包含，使用#pragma或其他允许重复包含的东西，那就更好了。

但是我们拥有我们所拥有的(除了你可能一次都没有#pragma)。

我不知道有什么性能上的好处，但它确实有效。我在我所有的c++项目中都使用它(当然我使用的是MS编译器)。我发现它比使用更有效

#ifndef HEADERNAME_H
#define HEADERNAME_H
...
#endif

它做同样的工作，并且不使用额外的宏填充预处理器。

GCC在3.4版正式支持#pragma。

我希望#pragma曾经(或类似的东西)出现在标准中。包含警卫并不是什么大问题(但向学习该语言的人解释它们似乎有点困难)，但这似乎是一个可以避免的小麻烦。

事实上，因为在99.98%的情况下，#pragma once行为是理想的行为，如果编译器能自动处理防止一个头文件被多次包含，使用#pragma或其他允许重复包含的东西，那就更好了。

但是我们拥有我们所拥有的(除了你可能一次都没有#pragma)。

性能的好处在于，一旦读取了#pragma，就不必重新打开文件。使用保护，编译器必须打开文件(这可能会浪费时间)来获得它不应该包含它的内容的信息。

这只是理论上的，因为对于每个编译单元，一些编译器将自动不打开没有任何读取代码的文件。

无论如何，并不是所有编译器都是这样，所以理想情况下，#pragma一旦出现就必须避免，因为跨平台代码根本就不是标准的/没有标准化的定义和效果。然而，实际上，它确实比守卫要好。

最后，在不检查每个编译器的行为的情况下，确保编译器具有最佳速度的更好建议是一次性使用pragma和守卫。

#ifndef NR_TEST_H
#define NR_TEST_H
#pragma once

#include "Thing.h"

namespace MyApp
{
 // ...
}

#endif

这样你就可以获得两者的优势(跨平台和帮助编译速度)。

由于打字时间较长，我个人使用一种工具来帮助生成所有这些信息(Visual Assist X)。

如今，老式的include守卫就像#pragma一样快。即使编译器没有特别对待它们，当它看到#ifndef WHATEVER和WHATEVER被定义时，它仍然会停止。现在打开一个文件非常便宜。即使有改进，也只是毫秒级的改进。

我只是不使用#pragma一次，因为它没有任何好处。为了避免与其他include守卫发生冲突，我使用了如下代码:CI_APP_MODULE_FILE_H——> CI =公司首字母;APP =应用程序名称;其余部分不言自明。

GCC从3.4开始支持#pragma一次，参见http://en.wikipedia.org/wiki/Pragma_once获得进一步的编译器支持。

我认为使用#pragma一次而不是包含守卫的最大好处是可以避免复制/粘贴错误。

让我们面对这个问题:我们大多数人很少从头开始一个新的头文件，而只是复制一个现有的头文件并根据我们的需要进行修改。使用#pragma创建一个工作模板比使用守卫要容易得多。对模板的修改越少，遇到错误的可能性就越小。在不同的文件中使用相同的include守卫会导致奇怪的编译器错误，并且需要一些时间来找出哪里出了问题。

#pragma once更容易使用。