我读到过，使用#pragma一次可以优化编译器，从而加快编译速度。我知道这是不标准的，因此可能会带来跨平台兼容性问题。
非windows平台(gcc)上的大多数现代编译器都支持这一点吗?
我希望避免平台编译问题，但也希望避免备用保护的额外工作:
#pragma once
#ifndef HEADER_H
#define HEADER_H
...
#endif // HEADER_H
我应该担心吗?我还需要在这上面花费更多的精力吗?
当前回答
我使用它，我很高兴，因为我必须键入更少，使一个新的标题。它在Windows、Mac和Linux三个平台上都运行得很好。
我没有任何性能信息，但我相信，与解析c++语法的缓慢相比，#pragma和include守卫之间的差异将是微不足道的。这才是真正的问题。例如，尝试用c#编译器编译相同数量的文件和行，看看有什么不同。
最后，使用guard或pragma根本不重要。
其他回答
#pragma once确实有一个缺点(除了不是标准的)，那就是如果你在不同的位置有相同的文件(我们有这样的情况是因为我们的构建系统会四处复制文件)，那么编译器会认为这些是不同的文件。
我不知道有什么性能上的好处，但它确实有效。我在我所有的c++项目中都使用它(当然我使用的是MS编译器)。我发现它比使用更有效
#ifndef HEADERNAME_H
#define HEADERNAME_H
...
#endif
它做同样的工作，并且不使用额外的宏填充预处理器。
GCC在3.4版正式支持#pragma。
不总是正确的。
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566有一个很好的例子，其中包括两个文件，但由于时间戳和内容相同(不相同的文件名)，误以为它们是相同的。
Additional note to the people thinking that an automatic one-time-only inclusion of header files is always desired: I build code generators using double or multiple inclusion of header files since decades. Especially for generation of protocol library stubs I find it very comfortable to have a extremely portable and powerful code generator with no additional tools and languages. I'm not the only developer using this scheme as this blogs X-Macros show. This wouldn't be possible to do without the missing automatic guarding.
我使用#ifndef/#define include守卫使用包含UUID的符号，如下所示:
#ifndef ARRAY__H_81945CB3_AEBB_471F_AC97_AB6C8B220314
#define ARRAY__H_81945CB3_AEBB_471F_AC97_AB6C8B220314 /* include guard */
#endif
我一直使用能够自动生成uuid的编辑器。 这可以防止与其他库中具有相同基本名称的文件发生名称冲突，并检测文件系统中的多个位置是否放置了完全相同的文件。
缺点是增加了表的大小，因为符号要大得多，但我还没有看到它的问题。
