名称的英文全称为：Standard Application Framework Extensions

所谓头档案预编译，就是把一个工程(Project)中使用的一些MFC标準头档案(如Windows.H、Afxwin.H)预先编译，以后该工程编译时，不再编译这部分头档案，仅仅使用预编译的结果。这样可以加快编译速度，节省时间。

afx曾经是微软一个专门的技术开发团队，而stdafx.h则是这个团队为了定义一些环境配置、参数设定等专门定义的。

Windows和MFC的include档案都非常大，即使有一个快速的处理程式，编译程式也要花费相当长的时间来完成工作。由于每个.CPP档案都包含相同的include档案，为每个.CPP档案都重複处理这些档案就显得很傻了。

为避免这种浪费，AppWizard和VisualC++编译程式一起进行工作，如下所示：

◎AppWizard建立了档案stdafx.h，该档案包含了所有当前工程档案需要的MFCinclude档案。且这一档案可以随被选择的选项而变化。

◎AppWizard然后就建立stdafx.cpp。这个档案通常都是一样的。

◎然后AppWizard就建立起工程档案，这样第一个被编译的档案就是stdafx.cpp。

◎当VisualC++编译stdafx.cpp档案时，它将结果保存在一个名为stdafx.pch的档案里。(扩展名pch表示预编译头档案。)

◎当VisualC++编译随后的每个.cpp档案时，它阅读并使用它刚生成的.pch档案。VisualC++不再分析Windowsinclude档案，除非你又编辑了stdafx.cpp或stdafx.h。

这个技术很精巧，你不这幺认为吗？(还要说一句，Microsoft并非是首先採用这种技术的公司，Borland才是。)在这个过程中你必须遵守以下规则：

◎你编写的任何.cpp档案都必须首先包含stdafx.h。

◎如果你有工程档案里的大多数.cpp档案需要的.h档案，顺便将它们加在stdafx.h(后部)上，然后预编译stdafx.cpp。

◎由于.pch档案具有大量的符号信息，它是你的工程档案里最大的档案。

如果你的磁碟空间有限，你就希望能将这个你从没使用过的工程档案中的.pch档案删除。执行程式时并不需要它们，且随着工程档案的重新建立，它们也自动地重新建立。

stdafx.h的作用

当我们使用AppWizard来自动生成某些项目的时候,系统会自动把所需要include的头档案在stdafx.h中先include一下,这样,我们只需要直接include这个stdafx.h档案即可.因为同一个项目中的不同源档案CPP都包含相同的include档案,这样,为每个.CPP档案都重複include这些档案就显得很傻了。

具体在stdafx.h中需要include什幺头档案,取决于用户在AppWizard中的选择.

比如:

#include <afxwin.h> // MFC core and standard components

#include <afxext.h> // MFC extensions

#include <afxole.h> // MFC OLE classes

#include <afxodlgs.h> // MFC OLE dialog classes

#include <afxdisp.h> // MFC Automation classes

......

等等,这样,就方便多了.所以,stdafx.h是自动生成的.这就使得用户在开发中不必在每一个cpp档案中都烦琐的include头档案了,而且,维护起来也方便.

在生成stdafx.h头档案的同时,也生成了stdafx.cpp源档案,该源档案只包含#include "stdafx.h"语句,这是在编译过程中第一个被编译的档案,编译的结果保存在一个名为stdafx.pch的档案里。 (扩展名pch表示预编译头档案。)当Visual C++编译随后的每个.cpp档案时，它阅读并使用它刚生成的.pch档案。 Visual C++不再分析Windows include档案，除非用户又编缉了stdafx.cpp或stdafx.h。

看了这样的讲解,我马上就实验了一下,自己新建立一个windows视窗项目,很快,就生成了stdafx.cpp和stdafx.h.

并且,在主源档案form1.cpp中,就include此头档案stdafx.h.

以上情况,只在使用AppWizard来自动生成项目的时候,才出现.否则,就没有必要include此头档案stdafx.h了

stdafx.h : 标準系统包含档案的包含档案。

Microsoft C 和 C++编译器提供了用于预编译任何 C 或 C++代码（包括内联代码）的选项。利用此性能特性，可以编译稳定的代码体，将已编译状态的代码存储在档案中，以及在随后的编译中，将预编译的代码与仍在开发的代码结合起来。由于不需要重新编译稳定代码，因此后面每次编译的速度都要快一些。

预编译代码有助于在开发周期中缩短编译时间，特别是在以下情况中：

一：总是使用不经常改动的大型代码体。

二：程式由多个模组组成，所有模组都使用一组标準的包含档案和相同的编译选项。在这种情况下，可以将所有包含档案预编译为一个预编译头。

三： 用于创建预编译头档案的第一次编译所花费的时间比后面的编译稍长一些。通过包含预编译代码可以加快后面的编译速度。C 和 C++ 程式都可以预编译。在 C++ 编程中，常见的做法是将类接口信息分别放到不同的头档案中。此后就可以将这些头档案包含在使用该类的程式中。通过预编译这些头档案，可以缩短程式的编译时间。

VC创建项目时自动创建的预编译头档案，在编译其他档案之前，VC先预编译此档案。头档案stdafx.h引入了项目中需要的一些通用的头档案，比如window.h等，在自己的头档案中包括stdafx.h就包含了那些通用的头档案。

预编译头档案通过编译stdafx.cpp生成，以工程名命名，由于预编译的头档案的后缀是“pch”，所以编译结果档案是projectname.pch。

编译器通过一个头档案stdafx.h来使用预编译头档案。stdafx.h这个头档案名称是可以在project的编译设定里指定的。编译器认为，所有在指令#include "stdafx.h"前的代码都是预编译的，它跳过#include "stdafx. h"指令，使用projectname.pch编译这条指令之后的所有代码。

因此，所有VC实现的CPP档案第一条语句都是：#include "stdafx.h"。

我们都知道，他是预编译头档案，就是说，我们在stdafx.cpp里include一次，生成一次pch，pdb档案，其他地方实际上直接用这个编译的结果，从而减少编译时间，提高编译效率。一般，我们把常用的不变的库头档案放里面，如，atlbase.h，atlcore.h，windows.h等，通常的com里import进来的dll，tlb也放这个里面，这样，它能做到，只编译一次，其他地方直接用编译出的结果。

以上是如果stdafx被正确使用时，它确实大大提高我们编程的效率（你工作中，有多少时间是在等编译完成？很多吧，这个时候一般都很无聊，无奈，浪费时间），但是他太容易用错了。

如果在其他的.h档案里也include "stdafx.h".则会产生问题

产生的问题描述：你的project里用了别人写的.h档案，导致你的编译速度奇慢无比，而且你做任何小的修改，编译都要好久好久，等的心烦，预编译根本没发挥作用。这个就可能给你h档案的人用错与编译档案了。

原因：由于你用到的.h档案里include了stdafx，他在他本身的project里，vs能够判断的出他是预编译头，也能找的到需要的pch，pdb档案。所以对写这个.h档案的人没影响。但是你作为他的客户，你工作在你的project下，你include了他的h头档案，而这时vs判断不出他的头档案里include的stdafx是预编译头档案，做普通档案编。那可想而知，他的stdafx里如果有import外面大型的库（如inventor的tlb，非常慢，我们犯了这个错），那编译速度简直是煎熬。最要命的是，以后你做任何简单的修改，这个stdafx都要重编，这和预编译解决的问题恰好相反了。

所以，绝对不要在h头档案里（特别是发布给外面人用的h头档案）里include你的stdafx.h!