我正在研究一个已知只能在Windows上运行并在Visual Studio下编译的代码库(它与excel紧密集成,所以它不会去任何地方).我想知道我是否应该使用传统的包含警卫或#pragma once用于我们的代码.我认为让编译器处理#pragma once会产生更快的编译,并且在复制和粘贴时不易出错.它也稍微不那么难看;)
注意:为了获得更快的编译时间,我们可以使用Redundant Include Guards,但这会在包含的文件和包含文件之间增加紧密耦合.通常它没关系,因为防护应该基于文件名,并且只有在你需要改变包含名称时才会改变.
我已经读过使用时会有一些编译器优化,#pragma once这会导致更快的编译.我认为这是非标准的,因此可能造成跨平台兼容性问题.
这是非Windows平台(gcc)上大多数现代编译器支持的东西吗？
我想避免平台编译问题,但也想避免后备警卫的额外工作:
#pragma once
#ifndef HEADER_H
#define HEADER_H
...
#endif // HEADER_H
我应该担心吗？我是否应该在这方面进一步消耗精力？
现代C和C++编译器支持非标准的#pragma once预处理器指令,它与经典的头部保护器具有类似的用途:
#ifndef hopefully_unique_identifier_that_doesnt_hurt_the_code
#define hopefully_unique_identifier_that_doesnt_hurt_the_code
// some code here
#endif
一个问题,我知道,使用经典的方法是,一旦你包含一个标题,你必须#undef使用标题保护宏再次包含它(这样做,对我来说,是一个主要的代码气味,但那是除此之外).该方法也出现了同样的问题#pragma once,但没有允许多次包含标题的可能性.
经典方法的另一个问题是,您可能会意外地在不相关的位置定义相同的宏,因此要么不包括预期的标题,要么做一些其他令人讨厌的东西,这是我无法想象的.这在实践中相当容易避免,通过遵守某些约定,例如将宏基于类似UUID的对象(即随机字符串)或(不太理想的方法),基于文件的名称,它们在.
在现实生活中,我很少遇到任何这些潜在问题,所以我并不认为它们是主要问题.
我能想到的唯一潜在的现实生活问题#pragma once是,它不是一个标准的东西 - 你依赖的东西可能无处不在,即使它存在,在实践中,无处不在(*).
那么,#pragma once除了我已经提到过的问题之外,还有哪些潜在的问题？我是否过于相信在实践中,无处不在？
(*)只有少数人使用的一些次要编译器,被排除在外.