是否需要冗余的防护装置？
Codegear RAD Studio 2009 中是否需要“冗余包含防护”？编译器是否足够聪明，可以自行处理这个问题？
例如，我可能在 foo.h 中具有以下“包含防护”：
#ifndef fooH
#define fooH
// ... declaration here
#endif
并在 use_foo.h 中具有以下“冗余包含防护”：
#ifndef fooH
#include "foo.h"
#endif
此外，如果编译器不够智能，则需要“冗余包含防护”（如果它们是）包含在源文件中。例如use_foo.cpp。 ？
Are 'redundant include guards' necessary in Codegear RAD Studio 2009? Is the compiler smart enough to deal with this on it's own?
For example, I might have the following 'include guard' in foo.h:
#ifndef fooH
#define fooH
// ... declaration here
#endif
and the following 'redundant include guard' in use_foo.h:
#ifndef fooH
#include "foo.h"
#endif
Additionally, if the compiler is not smart enough, are 'redundant include guards' necesarry if they are being included in a source file. e.g. use_foo.cpp. ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您标记为“冗余包含防护”的代码部分不是必需的，但它是可能的优化。
对于 C++Builder，有检测标头保护的逻辑，因此没有必要。
在一般情况下，无论如何，预处理过程通常都非常快，因此这种优化不太可能给你带来太多好处。
The portion of the code you marked as "redundant include guard" is not necessary but it is a possible optimization.
In the case of C++Builder, there is logic to detect header guards, so it should not be necessary.
In the general case, the preprocessing pass is usually pretty fast anyhow, so it's unlikely that this optimisation would buy you much anyhow.
这些冗余的包含防护旨在模拟所提议的#pragma Once指令的功能：如果已经包含了某些头文件，那么预处理器甚至不会再尝试定位、打开和解析它（因为它必须与“普通”包括防护技术一起使用）。在许多情况下，这使得包含文件的处理更加高效（加速编译）。
这种方法显然是一种高维护性的方法：必须确保头文件内部和外部的保护符号的拼写完全相同。
These redundant include guards are intended to emulate the functionality of the proposed
#pragma oncedirective: if some header file has already been included, then the preprocessor will not even attempt to locate, open and parse it anymore (as it would have to with the "ordinary" include guard technique). In many cases this makes handling of include files much more efficient (speeds up compilation).This approach is obviously a high-maintenance one: one has to make sure that the spelling of the guard symbol is exactly the same inside the header file as well as outside.
正如您所说，“冗余包含防护”可以加快编译速度。
如果没有冗余保护，编译器将迭代整个 foo.h 文件，查找可能位于
#ifndef块之外的代码。如果它是一个长文件，并且在很多地方都这样做了，编译器可能会浪费很多时间。但有了冗余保护，它可以跳过整个#include语句，甚至不重新打开该文件。当然，您必须进行试验并查看编译器迭代 foo.h 而没有实际编译任何内容所浪费的实际时间量；也许现代编译器实际上会寻找这种模式并自动知道根本不需要打开文件，我不知道。
（由280Z28开始编辑）
以下标头结构至少被GCC和MSVC识别。使用此模式实际上会抵消通过包含文件中的防护可以获得的所有好处。请注意，当编译器检查结构时，注释将被忽略。
（编辑结束）
The "redundant include guard", as you call it, speeds up compilation.
Without the redundant guard, the compiler will iterate the entire foo.h file, looking for some code that might be outside the
#ifndefblock. If it's a long file, and this is done many places, the compiler might waste a lot of time. But with the redundant guard, it can skip the entire#includestatement and not even reopen that file.Of course, you'd have to experiment and see the actual amount of time wasted by the compiler iterating through foo.h and not actually compiling anything; and perhaps modern compilers actually look for this pattern and automatically know not to bother opening the file at all, I don't know.
(Begin edit by 280Z28)
The following header structure is recognized by at least GCC and MSVC. Using this pattern negates virtually all benefits you could gain with guards in the including files. Note that comments are ignored when the compiler examines the structure.
(End edit)