因此,最近我在一个工作场所进行了讨论,其中我质疑使用双重包含 guard 对单个 guard 的使用。我所说的双重保护如下:

头文件“header_a.hpp”:

#ifndef __HEADER_A_HPP__
#define __HEADER_A_HPP__
...
...
#endif

在头文件或源文件中的任何位置包含头文件时:
#ifndef __HEADER_A_HPP__
#include "header_a.hpp"
#endif

现在,我知道在头文件中使用防护是为了防止多次包含已经定义的头文件,这是常见且有据可查的。如果已经定义了宏,则编译器会将整个头文件视为“空白”,并防止重复包含。很简单。

我不明白的问题是在#ifndef __HEADER_A_HPP__周围使用了#endif#include "header_a.hpp"。我的同事告诉我,这为夹杂物增加了第二层保护,但是我看不到如果第一层确实完成了工作(或做到了吗?),那么第二层是多么有用。

我能想到的唯一好处是,它可以彻底阻止链接程序费心查找文件。这是否是为了缩短编译时间(这没有被提及是有好处的),还是还有其他我看不到的东西在起作用?

最佳答案

我敢肯定,添加另一个包含后卫的做法是错误的做法:

#ifndef __HEADER_A_HPP__
#include "header_a.hpp"
#endif

原因如下:
  • 为了避免重复包含,在头文件本身内添加一个常规的include防护就足够了。它做得很好。另一个包含替代项的include防护只会使代码困惑并降低可读性。
  • 它添加了不必要的依赖项。如果您在头文件中更改包含保护,则必须在包含头的所有位置中进行更改。
  • 比较整个编译/链接过程,这绝对不是最昂贵的操作,因此它几乎不会减少总的构建时间。
  • 任何值得already optimizes file-wide include-guards的编译器。
  • 关于c++ - 在C++中使用双重包含保护,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/44629152/

    10-11 22:51
    查看更多