c++ - 前向声明对编译时间有多大影响？

Question

我对一些研究或经验数据非常感兴趣，这些研究或经验数据显示了两个相同的 c++ 项目之间的编译时间比较，除了一个尽可能使用前向声明而另一个不使用。

与完整包含相比，前向声明对编译时间的影响有多大？

#include "myClass.h"

对比

class myClass;

是否有任何研究对此进行检验？

我意识到这是一个模糊的问题，很大程度上取决于项目。我不希望有一个确切的数字来回答。相反，我希望有人可以指导我进行有关此的研究。

我特别担心的项目有大约 1200 个文件。每个 cpp 平均包含 5 个 header 。每个标题平均包含 5 个标题。这回归了大约 4 个级别。似乎对于每个编译的 cpp，必须打开和解析大约 300 个 header ，有些是多次。 (包含树中有很多重复项。)有守卫，但文件仍然打开。每个cpp都是用gcc单独编译的，所以没有header缓存。

为了确保没有人误解，我当然提倡尽可能使用前向声明。然而，我的雇主已经禁止他们了。我试图反对那个立场。

感谢您提供任何信息。

Answer 1

前向声明可以生成更简洁、更易于理解的代码，这肯定是任何决定的目标。

再加上一个事实，当涉及到类时，两个类很可能相互依赖，这使得不使用前向声明而不引起噩梦有点困难。

在 header 中同样前向声明类意味着您只需在实际使用这些类的 CPP 中包含相关 header 。这实际上减少了编译时间。

编辑:鉴于您上面的评论，我会指出包含头文件总是比转发声明慢。每当您包含一个 header 时，您通常需要从磁盘加载，结果却发现 header 保护意味着什么都没有发生。这将浪费大量时间，而且引入确实是一个非常愚蠢的规则。

编辑 2:很难获得硬数据。有趣的是，我曾经参与过一个对其 header 包含不严格的项目，并且在 512MB RAM P3-500Mhz 上构建时间大约为 45 分钟(这是前一阵子)。在花了 2 周时间减少包含噩梦(通过使用前向声明)后，我设法在不到 4 分钟的时间内构建了代码。随后尽可能使用前向声明成为规则。

编辑 3:还值得牢记的是，在对代码进行小的修改时，使用前向声明具有巨大的优势。如果整个商店都包含头文件，那么对头文件的修改可能会导致大量文件被重建。

我还注意到很多其他人都在赞美预编译头文件 (PCH) 的优点。他们有自己的位置，他们真的可以提供帮助，但他们真的不应该被用作正确前向声明的替代品。否则，对头文件的修改可能会导致重新编译大量文件(如上所述)以及触发 PCH 重建的问题。 PCH 可以为诸如预先构建的库之类的东西带来巨大的胜利，但它们没有理由不使用正确的前向声明。