Question

在分离依赖关系方面，使用stdafx.h的正确的方法是什么？

如果我把所有内容放在那里，那么我的编译速度非常快，我需要在任何文件中说明

#include "stdafx.h"

注意：

如果我把没有放在那里，我可以很好地组织一切 - 但随后我的编译速度大大降低。

如果我将所有内容放在并且中包含我个人文件中的每个标题，那么我会得到两个世界中最好的一点，但需要注意的是现在我需要跟踪同步问题。

这个问题是否有众所周知/广为接受的解决方案？

Answer 1

您不应将自己的头文件放在stdafx.h中，因为您的代码可能会更改并导致整个程序重新编译。

我通常会在其中放置标准标题和其他库，例如所有boost包含。

Answer 2

使用预编译头文件时，即使没有PCH，也应确保项目编译干净（因此将其视为优化，而不是替换每个TU中的包含）。除此之外，不要把所有内容都放在那里（更重要的是，不要在你自己的项目中放置标题 - PCH应该只包含那些不会很少改变或改变的 - 系统库，外部依赖项），而是尽量保持预编译最常用/最大的东西。

Answer 3

就个人而言，我宁愿编译速度慢，也不愿意（可见性）依赖关系。但是，一切都有限制。

由于每个项目都有自己的预编译头文件，所以我只是将common-to-all-includes放在那里。假如一个项目使用了一些那些适合那里的升级头，因为它们将被整个项目使用并且你不会改变它们。因此，在预编译的头文件中放置很少/永不更改的头文件，例如系统或第三方内容。

对于编译速度，我宁愿尽可能多地依赖于前向声明事物，拆分成较小的库并尝试查看事物是否可以以易失性代码不影响其他代码的重新编译的方式进行组织

Answer 4

Yor编译器可能有一个“show includes”标志。打开它，寻找重复的深层嵌套包含层次结构。考虑为每个这样的深树包含一个最浅的包含文件到您的标题。

Answer 5

有条件地包括PCH，然后定义类似“#define _PRE_COMPILE_”的内容这样原始标题仍然可见，如果您需要，代码是模块化的。这方面的一个例子是包括

#ifdef _PRE_COMPILE_
#include "stdafx.h"
#elif
#include <iostream>
#include <cstring>
#endif

在每个源文件的开头包含此内容。