14

就分离依赖项而言，正确的使用方法是什么？stdafx.h

如果我把所有东西都放在那里，那么我的编译速度很快，我需要在任何文件中说的是

#include "stdafx.h"

需要注意的是：

  1. 我不再知道哪些文件取决于哪些标题。
  2. 它降低了模块化，降低了我的代码可重用性。
  3. 我再也无法将 C#include与 C++ 分开（例如cstringvs string.h）而没有很大的痛苦。（说起来，这还重要吗？）

如果我什么都不放在那里，我可以很好地组织一切——但是我的编译速度会大大减慢。

如果我将所有内容都放在那里，并且在我的单个文件中包含每个标题，那么我将获得两全其美的效果，但需要注意的是，现在我必须跟踪同步问题。

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

4

5 回答 5

16

你不应该把你自己的头文件放进去，stdafx.h因为你的代码很可能会改变并且会导致你的整个程序重新编译。

我通常将标准头文件和其他库放在那里，例如所有 boost 包含。

于 2011-08-26T08:32:01.560 回答
7

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

于 2011-08-26T08:31:05.230 回答
1

就个人而言，我宁愿编译速度较慢，也不愿不知道（可见性）依赖关系如何。然而，凡事都有限度。

由于每个项目都有自己的预编译头文件，所以我只需将 common-to-all-includes 放在那里。假设一个项目使用了一些很适合那里的 boost headers，因为它们将被整个项目使用，而您不会更改它们。因此，将很少/从不更改的标题放在预编译的标题中，例如系统或第三方的东西。

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

于 2011-08-26T08:36:17.453 回答
1

你的编译器可能有一个“显示包含”标志。打开它，并寻找重复的深度嵌套的包含层次结构。考虑将最浅的包含文件之一包含到每个这样深的树的标题中。

于 2011-08-26T10:14:59.883 回答
0

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

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

在每个源文件的开头包含它。

于 2013-06-25T00:48:53.317 回答