我读到过,使用#pragma一次可以优化编译器,从而加快编译速度。我知道这是不标准的,因此可能会带来跨平台兼容性问题。
非windows平台(gcc)上的大多数现代编译器都支持这一点吗?
我希望避免平台编译问题,但也希望避免备用保护的额外工作:
#pragma once
#ifndef HEADER_H
#define HEADER_H
...
#endif // HEADER_H
我应该担心吗?我还需要在这上面花费更多的精力吗?
我读到过,使用#pragma一次可以优化编译器,从而加快编译速度。我知道这是不标准的,因此可能会带来跨平台兼容性问题。
非windows平台(gcc)上的大多数现代编译器都支持这一点吗?
我希望避免平台编译问题,但也希望避免备用保护的额外工作:
#pragma once
#ifndef HEADER_H
#define HEADER_H
...
#endif // HEADER_H
我应该担心吗?我还需要在这上面花费更多的精力吗?
当前回答
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.
其他回答
性能的好处在于,一旦读取了#pragma,就不必重新打开文件。使用保护,编译器必须打开文件(这可能会浪费时间)来获得它不应该包含它的内容的信息。
这只是理论上的,因为对于每个编译单元,一些编译器将自动不打开没有任何读取代码的文件。
无论如何,并不是所有编译器都是这样,所以理想情况下,#pragma一旦出现就必须避免,因为跨平台代码根本就不是标准的/没有标准化的定义和效果。然而,实际上,它确实比守卫要好。
最后,在不检查每个编译器的行为的情况下,确保编译器具有最佳速度的更好建议是一次性使用pragma和守卫。
#ifndef NR_TEST_H
#define NR_TEST_H
#pragma once
#include "Thing.h"
namespace MyApp
{
// ...
}
#endif
这样你就可以获得两者的优势(跨平台和帮助编译速度)。
由于打字时间较长,我个人使用一种工具来帮助生成所有这些信息(Visual Assist X)。
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.
主要的区别是编译器必须打开头文件来读取包含保护。相比之下,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慢很多。
GCC从3.4开始支持#pragma一次,参见http://en.wikipedia.org/wiki/Pragma_once获得进一步的编译器支持。
我认为使用#pragma一次而不是包含守卫的最大好处是可以避免复制/粘贴错误。
让我们面对这个问题:我们大多数人很少从头开始一个新的头文件,而只是复制一个现有的头文件并根据我们的需要进行修改。使用#pragma创建一个工作模板比使用守卫要容易得多。对模板的修改越少,遇到错误的可能性就越小。在不同的文件中使用相同的include守卫会导致奇怪的编译器错误,并且需要一些时间来找出哪里出了问题。
#pragma once更容易使用。