“C1083 无法打开预编译头文件”的处理与深入理解预编译头文件

前言

VS生成的项目结构有一些杂乱，所有代码文件都堆放在一起，于是对齐进行了整理，但是却出现了“C1083 无法打开预编译头文件”的错误。因此研究了一下应该如何规范地使用预编译头，达到加快项目编译速度的目的。

1、项目结构

2、修复方案

右键预编译头对应的cpp文件，选择“属性”

将其预编译头选项修改为“创建”

其他的文件仍然保持“使用”预编译头即可

为何这样配置

如果新建一个动态库DLL项目，它会自动帮你包含预编译头pch，参考它的配置可以发现，也是将pch文件配置为创建预编译头，其他文件使用预编译头即可。

简单来理解就是如上配置使得pch.cpp和pch.h预编译了其中包含的内容，并生成了.pch文件，用于给其他文件编译时访问。
通过预编译将预编译头中包含的文件提前编译保存在.pch文件中，其他文件编译时直接从预编译文件中取用即可，从而节约了项目的编译时间。

为什么使用预编译头

摘自该博客
https://blog.csdn.net/u012135461/article/details/78430236

      这得从头文件的编译原理讲起。其实头文件并不神秘，它的全部作用，就是把自己的所有内容直接“粘贴”到相应的 #include 语句处。如果不相信的话，不妨做个实验，将一个 cpp 中的所有 #include 语句删掉，并将它包含的文件粘贴到相应的位置，你会发
现，文件的编译和运行都完全没有受到影响。其实，编译器在编译你的程序的时候，所做的第一件事，也就是展开所有的 #include 语句和 #define 语句。
     
     头文件的出现，固然给书写程序带来了很大方便。可是到了 Windows 时代后，慢慢就呈现出一些问题了。几乎所有的 Windows 程序都必须包含 windows.h，而那个文件却硕大无比，将它展开后往所有文件中一粘贴，编译的时候立刻慢得像只蜗牛。
     
      到了 MFC 时代后，情况更为恶劣了。毕竟 C 风格的 Windows 头文件里面包含的还仅仅是函数定义和宏，编译难度不算太大，而 MFC 库里面的头文件可都是类声明啊！更何况，一个最简单的工程，都会生成大量的类，需要用到大量的函数。如果工程稍微复杂一些，编译难度可想而知！
     
      但是，人们惊奇地发现，虽然用到的头文件又多又杂，但是在一个工程中，总有那么一堆头文件，是几乎所有 cpp 都必须包含的。那么，可不可以把这些头文件提取出来，只编译一编，然后所有其它 cpp 就都能使用呢？没错，这就是预编译头的思想都由来！
     
      实践证明，使用了预编译头技术后，编译速度大大提高了。可以到你的工程目录下的Debug 或 Release 目录中看一看，里面有一个体积极为硕大的 .pch 文件，那就是传说中的“编译之后的预编译头”。
     
      使用了预编译头技术后，虽然带来了极大地方便，但也造成了一个问题：由于它假定预编译头中包含过的头文件会在所有 cpp 中使用，因此它在编译你的 cpp 的时候，就会将预编译头中已经编译完的部分加载到内存中。如果它突然发现你的 cpp 居然没有包含预编译头，它就会很郁闷，因为它不知道该如何将已编译完的部分从内存中请出去，整个编译过程就会失败。
     
     因此，如果你使用了预编译头技术，就必须在所有的 cpp 中包含预编译头。MFC 工程中为你建立了一个默认的预编译头 stdafx.h，如果你愿意，也可以在自己的工程中使用其它文件名作为你的预编译头，如果你觉得有必要。