在C ++中使用双重包含保护

因此，我最近在我的工作地点进行了讨论，其中我质疑使用双重包含保护而不是单个保护。我所说的双重保护如下：

头文件“ 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

原因如下：

1. 为了避免重复包含，只需在头文件本身内添加一个常规的包含保护即可。它做得很好。另一个包含替代项的include防护只会使代码混乱并降低可读性。

2. 它增加了不必要的依赖性。如果在头文件中更改包含保护，则必须在包含头的所有位置进行更改。

3. 比较整个编译/链接过程，绝对不是最昂贵的操作，因此它几乎不会减少总构建时间。

4. 任何有价值的编译器 已经可以优化整个文件的include-guards。

在头文件中放置包含保护的原因是为了防止将头的内容多次拉入翻译单元。这是正常的，长期存在的做法。

在源文件中放置冗余包含防护的原因是避免不得不打开要包含的头文件，而在较早的年代可以大大加快编译速度。如今，打开文件的速度比以前快得多。此外，编译器非常聪明地记住他们已经看过的文件，并且他们了解include Guard习惯用法，因此可以自己弄清楚自己不需要再次打开该文件。有点麻烦，但是最重要的是不再需要这个额外的图层。

编辑：这里的另一个因素是，编译C ++是远远复杂得多，编译C，所以它需要远远更长的时间，使花开放的时间包含文件需要编译转换单元中，时间更小，更显著部分。

我能想到的唯一好处是，它可以彻底阻止链接程序费心查找文件。

链接器不会受到任何影响。

它可以防止预处理程序费心查找文件，但是，如果定义了防护措施，则意味着它已经找到了文件。我怀疑，如果完全减少了预处理时间，那么除了在病理上最递归地包含怪物的情况之外，其影响将是很小的。

不利的一面是，如果曾经更改过防护（例如，由于与另一个防护发生冲突），则必须更改include指令之前的所有条件，以使其起作用。如果其他东西使用了先前的保护措施，则必须更改条件，以使include指令本身能够正常工作。

PS__HEADER_A_HPP__是为实现保留的符号，因此您不能定义它。为卫队使用另一个名称。

在更传统的（大型机）平台上的较旧的编译器（我们在这里指的是2000年代中期）不曾具有其他答案中描述的优化，因此它确实确实大大降低了必须重新读取头文件的预处理时间。已经包含在内（请记住，在一个大型的，整体的企业级项目中，您将包含很多头文件）。作为示例，我看到的数据表明，具有256个头文件的文件的速度提高了26倍，每个头文件在AIX编译器的VisualAge C ++ 6上可追溯到2000年代中期，每个头文件包括相同的256个头文件。这是一个极端的例子，但是这种提速确实加起来。

但是，所有现代编译器，即使在诸如AIX和Solaris之类的大型机平台上，也执行了足够的优化以包含标头，这使得如今的差异确实可以忽略不计。因此，没有充分的理由再拥有这些。

但是，这确实解释了为什么有些公司仍然坚持这种做法，因为相对最近（至少在C / C ++代码库时代而言），对于大型的整体项目仍然值得。

尽管有人对此表示反对，但实际上“ #pragma一旦”可以完美地工作，并且主要的编译器（gcc / g ++，vc ++）都支持它。

因此，无论人们在传播什么纯粹主义的论点，它的效果都会更好：

1. 快速
2. 无需维护，神秘的不包含项不会带来麻烦，因为您复制了旧标记
3. 具有明显含义的单行与文件中散布的神秘行

简而言之：

#pragma once

在文件的开头，仅此而已。优化，可维护，随时可用。