清理遗留代码“header spaghetti”

Question

任何清理“标题意大利面”的推荐做法，这会导致极其严重的后果 编译时间慢（Linux/Unix）？

GCC 中是否有相当于“#pragma Once”的东西？
（发现与此相关的冲突消息）

谢谢。

Answer 1

假设您熟悉“包含防护”（#ifdef 在标头开头......），加快构建时间的另一种方法是使用外部包含防护。
它在“大规模 C++ 软件设计<中进行了讨论/a>”。 这个想法是，经典的包含防护与 #pragma Once 不同，不会让您从第二次开始就忽略标头所需的预处理器解析（即它仍然必须解析并查找包含防护的开头和结尾。外部包含防护将 #ifdef 放置在 #include 行本身周围，

因此它看起来像这样：

#ifndef MY_HEADER
#include "myheader.h"
#endif

当然，在 H 文件中，您有经典的包含防护，

#ifndef MY_HEADER
#define MY_HEADER

// content of header

#endif

这样 myheader.h 文件甚至不会被打开/解析。预处理器，它可以在大型项目中为您节省大量时间，特别是当头文件位于共享远程位置时，就像有时一样

，这一切都在那本书中。

Answer 2

如果您想要进行彻底的清理并且有时间，那么最好的解决方案是删除所有文件中的所有 #include（除了明显的文件，例如 abc.cpp 中的 abc.h），然后编译项目。 添加必要的前向声明或标头来修复第一个错误，然后重复直到完全完成。

这并不能解决可能导致包含问题的根本问题，但它确实确保唯一的包含是必需的。

Answer 3

理查德是对的（为什么他的解决方案被记下来？）。

无论如何，所有 C/C++ 标头都应使用内部包含防护。

这就是说，要么：

1 - 你的遗留代码不再被真正维护，你应该使用预编译头（这是一个黑客，但是嘿......你需要的是加速你的编译，而不是重构未维护的代码）

2 - 您的遗留代码仍然有效。 然后，您可以使用预编译标头和/或守卫/外部守卫作为临时解决方案，但最终，您需要删除所有包含文件（一次一个 .C 或 .CPP），然后编译每个 .C 或 .CPP 文件。 C 或 .CPP 文件一次一个，使用前向声明或必要时包含来更正其包含（或者甚至将大包含分解为较小的包含以确保每个 .C 或 .CPP 文件仅获得其所需的标头）。 无论如何，测试和删除过时的包含是项目维护的一部分，所以...

我自己在预编译头方面的经验并不完全是一个好的经验，因为有一半的时间，编译器找不到我定义的符号，所以我尝试了完整的“清理/重建”，以确保它不是过时的预编译头。 所以我的猜测是将它用于您甚至不会接触的外部库（例如 STL、C API 标头、Boost 等）。 不过，我自己的经验是使用 Visual C++ 6，所以我猜（希望？）他们现在做对了。

现在，最后一件事：标头应该始终是自给自足的。 这意味着如果标头的包含取决于包含的顺序，那么就会遇到问题。 例如，如果您可以写：

#include "AAA.hpp"
#include "BBB.hpp"

但不能写：

#include "BBB.hpp"
#include "AAA.hpp"

因为 BBB 依赖于 AAA，那么您所拥有的只是您从未在代码中承认的依赖关系。 不通过定义确认它只会使您的编译成为一场噩梦。 BBB 也应该包括 AAA（即使它可能会慢一些：最后，前向声明无论如何都会清除无用的包含，因此您应该有一个更快的编译计时器）。

Answer 4

我读到，GCC 认为 #pragma Once 已弃用，尽管即使 #pragma Once 也只能做这么多来加快速度。

要尝试解开#include意大利面条，您可以查看doxygen。 它应该能够生成包含标题的图表，这可能会给您带来简化事物的优势。 我无法立即回忆起详细信息，但图形功能可能需要您安装 GraphViz 并告诉 doxygen可以找到 GraphViz 的 dotty.exe 的路径。

如果编译时间是您最关心的问题，您可能会考虑的另一种方法是设置预编译标头。

Answer 5

感谢您的回复，但问题是关于现有代码，其中包括严格的“包含顺序”等。
问题是是否有任何工具/脚本可以澄清实际发生的情况。

标头防护不是解决方案，因为它们不会阻止编译器一次又一次地读取整个文件......

Answer 6

PC-Lint 将对清理意大利面标头大有帮助。 它还将为您解决其他问题，例如未初始化的变量不可见等。

Answer 7

正如 onebyone.livejournal.com 在回答您的问题时评论的那样，一些编译器支持 包括防护优化，我链接的页面定义如下：

包含保护优化是指编译器识别上述内部包含保护习惯用法并采取措施避免多次打开文件。 编译器可以查看包含文件，去掉注释和空格，并确定整个文件是否在包含保护范围内。 如果是，它将存储文件名并在映射中包含保护条件。 下次要求编译器包含该文件时，它可以检查包含保护条件并决定是跳过该文件还是#include 它而不需要打开该文件。

话又说回来，您已经回答了外部包含防护并不是您问题的答案。 对于解开必须以特定顺序包含的头文件，我建议如下：

• 每个 .c 或 .cpp 文件应该 #include首先是相应的 .h 文件，其余的 #include 指令应按字母顺序排序。 当这破坏了头文件之间未声明的依赖关系时，您通常会收到构建错误。
• 如果您有一个头文件定义基本类型的全局 typedef 或用于大部分代码的全局 #define 指令，则每个 .h 文件应 #首先包含 该文件，其其余的#include 指令应按字母顺序排序。
• 当这些更改导致编译错误时，您通常必须以 #include 的形式从一个头文件添加到另一个头文件的显式依赖项。
• 当这些更改不会导致编译错误时，它们可能会导致行为更改。 希望您有某种可以用来验证应用程序功能的测试套件。

听起来问题的一部分可能是增量构建比应有的速度慢得多。 正如其他人指出的那样，可以通过前向声明或分布式构建系统来改善这种情况。

Answer 8

使用其中的一个或多个来加快构建时间

1. 使用预编译头
2. 使用缓存机制（例如 scons）
3. 使用分布式构建系统（ distcc、Incredibuild($) ）

Answer 9

在标头中：仅当您无法使用前向声明时才包含标头，但始终 #include 您需要的任何文件（包含依赖项是邪恶的！）。

Answer 10

正如另一个答案中提到的，您绝对应该尽可能使用前向声明。 据我所知，GCC 没有任何与#pragma Once 等价的东西，这就是为什么我坚持使用包含守卫的旧时尚风格。

Answer 11

前几天我读到了一个减少标头依赖性的巧妙技巧：编写一个脚本，该脚本将

• 找到所有 #include 语句
• 一次删除一个语句，
• 如果编译失败则重新编译，将 include 语句添加回

最后，您希望最终在您的代码中包含最少所需的内容。 您可以编写一个类似的脚本，重新排列包含以查明它们是否是自给自足的，或者要求在它们之前包含其他标头（首先包含标头，查看编译是否失败，报告它）。 这应该有助于清理你的代码。

更多注意事项：

• 现代编译器（其中包括 gcc）可识别标头保护，并以与 pragma Once 相同的方式进行优化，仅打开文件一次。

• 当同一个文件在文件系统中具有不同的名称（即带有软链接）时，pragma Once 可能会出现问题

• gcc 支持 #pragma Once，但称其为“过时”

• pragma Once 并非所有编译器都支持，而且不是部分编译器支持C 标准

• 不仅编译器可能会出现问题。 像 Incredibuild 这样的工具也有 #pragma Once 的问题