#pragma once确实有一个缺点(除了不是标准的)，那就是如果你在不同的位置有相同的文件(我们有这样的情况是因为我们的构建系统会四处复制文件)，那么编译器会认为这些是不同的文件。

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

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

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

我使用它，我很高兴，因为我必须键入更少，使一个新的标题。它在Windows、Mac和Linux三个平台上都运行得很好。

我没有任何性能信息，但我相信，与解析c++语法的缓慢相比，#pragma和include守卫之间的差异将是微不足道的。这才是真正的问题。例如，尝试用c#编译器编译相同数量的文件和行，看看有什么不同。

最后，使用guard或pragma根本不重要。

我使用#ifndef/#define include守卫使用包含UUID的符号，如下所示:

#ifndef ARRAY__H_81945CB3_AEBB_471F_AC97_AB6C8B220314
#define ARRAY__H_81945CB3_AEBB_471F_AC97_AB6C8B220314 /* include guard */


#endif

我一直使用能够自动生成uuid的编辑器。 这可以防止与其他库中具有相同基本名称的文件发生名称冲突，并检测文件系统中的多个位置是否放置了完全相同的文件。

缺点是增加了表的大小，因为符号要大得多，但我还没有看到它的问题。

主要的区别是编译器必须打开头文件来读取包含保护。相比之下，pragma只会导致编译器跟踪该文件，并且在遇到针对同一文件的另一个include时不执行任何文件IO。虽然这听起来可以忽略不计，但它可以很容易地扩展到大型项目，特别是那些没有好的标题包括学科的项目。

也就是说，现在的编译器(包括GCC)足够聪明，可以像对待pragma一样对待include守卫。例如，他们不打开文件，避免文件IO惩罚。

在不支持pragma的编译器中，我见过手动实现有点麻烦。

#ifdef FOO_H
#include "foo.h"
#endif

我个人喜欢#pragma once方法，因为它避免了命名冲突和潜在的拼写错误的麻烦。相比之下，它的代码也更加优雅。也就是说，对于可移植的代码，如果编译器不同意，那么两者都使用也无妨。

使用#pragma一次应该适用于任何现代编译器，但我不认为有任何理由不使用标准的#ifndef include guard。它工作得很好。需要注意的是，GCC在3.4版之前一次都不支持#pragma。

我还发现，至少在GCC上，它可以识别标准的#ifndef include guard并对其进行优化，因此它应该不会比#pragma慢很多。