我有一个Visual Studio C ++基于程序使用预编译的头（ stdafx.h ）。 现在，我们正在移植用gcc 4.x的应用到Linux
现在的问题是如何处理的预编译的头在两种环境。 我GOOGLE了，但不能得出一个结论。
很显然，我想离开stdafx.h在Visual Studio中，因为代码库是相当大的和预编译头提升编译时间。
但问题是如何在Linux平台上。 这是我发现：
- 保留
stdafx.h原样。 GCC编译代码比相当快VC ++（或者它只是我的Linux机器是强... :)），所以我也许满意这个选项。 使用方法从这里 -让stdafx.h看起来像台（套USE_PRECOMPILED_HEADER仅VS）：
#ifdef USE_PRECOMPILED_HEADER ... my stuff #endif
从使用的方法在这里 -编译VC ++与/FI 隐含地包括stdafx.h每个CPP文件。 因此，在VS你的代码可以轻松切换无需预编译头被编译并没有代码将不得不改变。
我个人不喜欢依赖和混乱stdafx.h被推向一个很大的代码库。 因此，选项是吸引我-在Linux上你没有stdafx.h ，同时仍然能够通过打开的VS预编译头/FI只。
- 在Linux编译
stdafx.h只是作为一个预编译的头（模仿的Visual Studio）
你的意见？ 还有没有其他的方法来治疗的问题？
Answer 1:
你最好使用预编译头仍然是最快的编译。
您可以在GCC使用预编译头为好。 看到这里 。
编译后的预编译的头将具有所附作为扩展.gch代替.pch 。
因此，举例来说，如果你预编译stdafx.h中，你将有将名为自动搜索的预编译头stdafx.h.gch任何时候你包括stdafx.h
例：
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.我已经与两个不同版本的VS和海湾合作委员会在Linux上预编译头（博客文章关于这个实验在这里和这里 ）。 根据我的经验，VS是很多的包括路径的长度比较敏感，目录中包括路径编号和数量包含文件比G ++是。 当我测量构建时间妥善安排预编译头会做出VS下的编译时间，而G ++是由这个几乎不为所动一个巨大的差异。
事实上，基于以上我做什么我最后一次上一个项目，这是必要的编译时间收服工作是预编译stdafx.h中的Windows下的等价物的地方是有道理的，只是把它作为一个普通的文件在Linux下。
Answer 4:
很简单的解决方案。 添加在Linux环境“stdafx.h中”虚拟文件条目。
Answer 5:
我只会在一个大的团队的开发人员使用选项1。 选项2，3，4往往会阻止你的团队的其他成员的工作效率，这样可以节省一天在编译时几分钟。
这是因为：
让我们假设你的开发人员使用一半VS，一半使用GCC。 时不时地，一些开发商VS会忘记在.cpp文件头。 他不会注意到，因为stdafx.h中隐含了它。 于是，他推了他的版本控制的更改，然后海合会队的一些其他成员会得到编译器错误。 因此，对于每5分钟-A-一天，你获得通过使用预编译头，5别人废弃物通过固定丢失的报头。
如果您不同意在所有的编译器相同的代码，你会遇到这样的每一天的问题。 如果你强迫你的VS开发人员将改变之前检查编纂GCC，那么你会扔掉使用预编译的头所有的生产力。
选项4娓娓动听，但如果你想在某个时间点使用其他的编译器是什么？ 选择4只，如果你只使用VS和gcc的作品。
请注意，选项1可能使GCC编译挨几秒钟。 虽然它可能不显着。
Answer 6:
这很简单，真的：
项目 - >项目设置（ALT + F7）
项目 - 设置 - 对话框：
C ++ - >类别：预编译头 - >预编译头单选按钮 - >禁用
Answer 7:
由于stdafx.h默认情况下所有的Windows的具体的东西，我已经把一个空stdafx.h我的其他平台。 这样，你的源代码保持一致，同时有效地禁止stdafx在Linux上，而无需去除所有#include "stdafx.h"从您的代码行。
Answer 8:
如果你在你的项目中使用CMake的，那么有哪些自动为您模块，非常方便，例如看到cmake的，预编译头 在这里 。 要使用它，包括模块和呼叫：
include( cmake-precompiled-header/PrecompiledHeader.cmake )
add_precompiled_header( ${target} ${header} FORCEINCLUDE SOURCE_CXX ${source} )
所谓Cotire另一个模块创建要预编译头文件（无需手动编写StdAfx.h中），加快构建以其他方式-看这里 。
Answer 9:
我已经做了，没有问题的跨平台代码都选择2（的#ifdef）和选项4（PCH为GCC）。
我发现GCC编译速度远远超过VS所以预编译头一般都没有那么重要，除非你正在引用一些巨大的头文件。
Answer 10:
我有一个情况＃2特别是没有为我工作（有许多VS建立CONFIGS其中#ifdef各地#include "stdafx.h"不工作）。 其他的解决方案是不理想的，因为这些文件本身是跨项目，以及作为跨平台的。 我不想强迫预处理宏被设定或强制的Linux，甚至窗户建立使用（或不使用）PCH，所以...
我做了什么，给定一个名为文件notificationEngine.cpp ，例如，去除#include stdafx.h线完全，造成了所谓的同一个目录中的新文件pchNotificationEngine.cpp具有以下内容：
#include "stdafx.h"
#include "notificationEngine.cpp"
任何给定的项目可以只包含文件的正确版本。 这固然可能是不适合那些仅由单个项目cpp文件的最佳选择。
文章来源: Handling stdafx.h in cross-platform code
