我读到过,使用#pragma一次可以优化编译器,从而加快编译速度。我知道这是不标准的,因此可能会带来跨平台兼容性问题。

非windows平台(gcc)上的大多数现代编译器都支持这一点吗?

我希望避免平台编译问题,但也希望避免备用保护的额外工作:

#pragma once
#ifndef HEADER_H
#define HEADER_H

...

#endif // HEADER_H

我应该担心吗?我还需要在这上面花费更多的精力吗?


当前回答

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

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

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

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

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

其他回答

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

#ifndef HEADERNAME_H
#define HEADERNAME_H
...
#endif

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

GCC在3.4版正式支持#pragma。

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

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

Using '#pragma once' might not have any effect (it is not supported everywhere - though it is increasingly widely supported), so you need to use the conditional compilation code anyway, in which case, why bother with '#pragma once'? The compiler probably optimizes it anyway. It does depend on your target platforms, though. If all your targets support it, then go ahead and use it - but it should be a conscious decision because all hell will break loose if you only use the pragma and then port to a compiler that does not support it.

不总是正确的。

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566有一个很好的例子,其中包括两个文件,但由于时间戳和内容相同(不相同的文件名),误以为它们是相同的。

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

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

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