VC中的Stdafx(转)

参考：http://blog.csdn.net/thimin/archive/2007/03/28/1544378.aspx

略有改动

    Windows和MFC的include文件都非常大，即使有一个快速的处理程序，编译程序也要花费相当长的时间来完成工作。由于每个.CPP文件都包含相同的include文件，为每个.CPP文件都重复处理这些文件就显得很傻了。
    为避免这种浪费，AppWizard和VisualC++编译程序一起进行工作，如下所示：
        1)AppWizard建立了文件stdafx.h，该文件包含了所有当前工程文件需要的MFCinclude文件。且这一文件可以随被选择的选项而变化。
        2)AppWizard然后就建立stdafx.cpp。这个文件通常都是一样的。
        3)然后AppWizard就建立起工程文件，这样第一个被编译的文件就是stdafx.cpp。
        4)当VisualC++编译stdafx.cpp文件时，它将结果保存在一个名为stdafx.pch的文件里。(扩展名pch表示预编译头文件。)
        5)当VisualC++编译随后的每个.cpp文件时，它阅读并使用它刚生成的.pch文件。VisualC++不再分析Windows include文件，除非你又编缉了stdafx.cpp或stdafx.h。
       在这个过程中你必须遵守以下规则：
        1)你编写的任何.cpp文件都必须首先包含stdafx.h。
        2)如果你有工程文件里的大多数.cpp文件需要的.h文件，顺便将它们加在stdafx.h(后部)上，然后预编译stdafx.cpp。
        3)由于.pch文件具有大量的符号信息，它是你的工程文件里最大的文件。

    对于.h文件，可以不包含stdafx.h，其实也不用包含

=====================================================================

对于工程量比较大的项目，一定要注意文件之间的编译顺序，合理的放置#include ".h"的位置和次序，以及合理的使用#ifdef，进行编译控制

4月23号调试程序的时候，碰到了一个问题，就是头文件的循环编译，产生了一大堆的问题：编译错误，就是自定义的变量被编译器认为是undefined

模型是这样子的

A.h中 #include "c.h"

B.h中#include "A.h"

C.h中#include "B.h"

//这样便形成了循环编译的问题，假设编译最早是从A开始的，在B.h被触发编译时，A.h还没有被编译。那么A中的变量在B中，被编译器认为是undefined的，便产生了循环编译的情况

一般的头文件应该放在.h文件中进行#include的，但是有可能产生循环编译的情况时，可在CPP文件中包含相应的头文件，从而破解循环编译