在跨平台代码中处理 stdafx.h

Question

我有一个基于 Visual Studio C++ 的程序，它使用预编译头 (stdafx.h)。 现在我们使用 gcc 4.x 将应用程序移植到 Linux。

问题是如何在两种环境中处理预编译头。 我用谷歌搜索过但无法得出结论。

显然，我想将 stdafx.h 保留在 Visual Studio 中，因为代码库相当大，而且预编译头会增加编译时间。

但问题是在 Linux 中做什么。 这就是我发现的：

1. 将 stdafx.h 保留原样。 gcc 编译代码的速度比 VC++ 快得多（或者只是我的 Linux 机器更强......:)），所以我可能对这个选项感到满意。

2. 使用此处中的方法 - 使 stdafx.h 看起来像 (仅针对 VS 设置USE_PRECOMPILED_HEADER）：

   <预><代码>#ifdef USE_PRECOMPILED_HEADER ... 我的东西 ＃万一

3. 使用 此处 - 使用 /FI 编译 VC++，以隐式在每个 cpp 文件中包含 stdafx.h 。 因此，在 VS 中，您的代码可以轻松切换为无需预编译标头的编译，并且无需更改任何代码。
   我个人不喜欢依赖关系，而混乱的 stdafx.h 正在推动一个庞大的代码库的发展。 因此这个选项对我很有吸引力 - 在 Linux 上你没有 stdafx.h，但仍然能够仅通过 /FI 在 VS 上打开预编译头文件.

4. 在 Linux 上仅将 stdafx.h 编译为预编译头（模仿 Visual Studio）

您的意见是？ 还有其他方法来处理这个问题吗？

Answer 1

您最好仍然使用预编译头以获得最快的编译速度。

您也可以在 gcc 中使用预编译头。 请参见此处。

编译后的预编译头将附加一个扩展名 .gch 而不是 .pch。

因此，例如，如果您预编译 stdafx.h，您将拥有一个预编译标头，每当您包含 stdafx.h 时，都会自动搜索名为 stdafx.h.gch 的预编译标头

示例：

stdafx .h:

#include <string>
#include <stdio.h>

a.cpp:

#include "stdafx.h"
int main(int argc, char**argv)
{
  std::string s = "Hi";
  return 0;
}

然后编译为：

<代码>> g++ -c stdafx.h -o stdafx.h.gch
<代码>> g++ a.cpp
<代码>> ./a.out

即使您在步骤 1 之后删除了 stdafx.h，您的编译也将正常工作。

Answer 2

上次我需要做同样的事情时，我使用了 选项 3 。 我的项目很小，但效果非常好。

Answer 3

我要么选择选项 4，要么选择选项 2。我已经在 Linux 上的各种 VS 版本和 GCC 上尝试过预编译头（关于此的博客文章 此处 和 此处< /a>）。 根据我的经验，VS 对包含路径的长度、包含路径中的目录数量以及包含文件的数量比 G++ 更敏感。 当我测量构建时间时，正确排列的预编译头会对 VS 下的编译时间产生巨大的影响，而 G++ 对此几乎不感兴趣。

实际上，根据上面的内容，我上次在一个项目中所做的事情是在 Windows 下预编译 stdafx.h 的等效项，这很有意义，并且只需将其用作常规文件即可。在Linux下。

Answer 4

非常简单的解决方案。
在 Linux 环境中添加“stdafx.h”的虚拟文件条目。

Answer 5

我只会在大型开发团队中使用选项 1。
选项 2、3 和 4 通常会降低团队其他成员的工作效率，因此您每天可以节省几分钟的编译时间。

原因如下：

假设一半的开发人员使用 VS，一半使用 gcc。
有时，一些 VS 开发人员会忘记在 .cpp 文件中包含标头。
他不会注意到，因为 stdafx.h 隐式包含它。 因此，他将更改推送到版本控制中，然后 gcc 团队的其他一些成员将收到编译器错误。
因此，每天您通过使用预编译标头获得的每 5 分钟时间，就会有 5 个其他人通过修复您丢失的标头而浪费时间。

如果您不在所有编译器之间共享相同的代码，那么您每天都会遇到类似的问题。 如果您强制 VS 开发人员在推送更改之前检查 gcc 上的编译情况，那么您将放弃使用预编译头所获得的所有生产力收益。

选项 4 听起来很有吸引力，但如果您想在某个时间点使用另一个编译器怎么办？ 仅当您仅使用 VS 和 gcc 时，选项 4 才有效。

请注意，选项 1 可能会使 gcc 编译花费几秒钟的时间。 尽管它可能不明显。

Answer 6

真的很简单：

项目->项目设置（Alt + F7）

项目设置对话框：
C++-> 类别：预编译头文件 -> 预编译头单选按钮 --> 禁用

Answer 7

由于 stdafx.h 默认情况下是所有 Windows 特定的内容，因此我在其他平台上放置了一个空的 stdafx.h 。 这样，您的源代码将保持相同，同时在 Linux 上有效禁用 stdafx，而无需从代码中删除所有 #include "stdafx.h" 行。

Answer 8

如果您在项目中使用 CMake，那么有一些模块可以为您自动化它，非常方便，例如参见 cmake-precompiled-header 此处。 要使用它，只需包含该模块并调用：

include( cmake-precompiled-header/PrecompiledHeader.cmake )
add_precompiled_header( ${target} ${header} FORCEINCLUDE SOURCE_CXX ${source} )

另一个名为 Cotire 的模块创建要预编译的头文件（无需手动编写 StdAfx.h）并以其他方式加速构建 - 请参阅此处。

Answer 9

我已经为跨平台代码完成了选项 2 (#ifdef) 和选项 4 (PCH for gcc)，没有任何问题。

我发现 gcc 的编译速度比 VS 快得多，因此预编译头通常不是那么重要，除非您引用一些巨大的头文件。

Answer 10

我遇到的情况是 #2 特别不适合我（有许多 VS 构建配置，其中 #ifdef 周围的 #include "stdafx.h" 不起作用工作）。 其他解决方案并不是最理想的，因为文件本身是跨项目和跨平台的。 我不想强制设置预处理器宏或强制 linux 甚至 windows 构建使用（或不使用）pch，所以...

我所做的，给定一个名为 notificationEngine.cpp 的文件，例如，完全删除了 #include stdafx.h 行，在同一目录中创建了一个名为 pchNotificationEngine.cpp 的新文件，其中包含以下内容：

#include "stdafx.h"
#include "notificationEngine.cpp"

任何给定的项目都可以包括文件的正确版本。 诚然，对于仅由单个项目使用的 cpp 文件来说，这可能不是最佳选择。