一个单文件的C语言源程序也是一个C项目。
在之前用C语言编程的时候，往往都是随意地新建一个.c或.cpp文件，把代码往里面一写，gcc命令一敲，然后就在命令行里运行自己的程序，开始快乐苦B的debug之旅了。直到最近学习编译原理，了解了一些程序解析的原理之后，才开始把这个曾经思考过，却又未曾放在心上的问题拿出来解决。
在看了这篇文章之后，有了一定的新认识，决定也自己写点东西来加深一下理解。（看起来是位高中物竞，大学计科的dalao啊）
首先提出一个问题：C语言中的.c、.h读者有见到过吗？在使用时，有注意到自己是在何种情况下使用两者的吗？
显然，一个接触过C语言的人，是一定见到过这两者的。因为，即使是一个编程界最基础的程序Hello World，在使用C语言编写时也必须同时用到这两种类型的文件。
回忆一下，步骤如下：
- 建立
helloworld.c；
-
使用任意文本编辑器（如记事本）打开，在内部输入如下内容：
#include <stdio.h>
int main()
{
printf("Hello world!\n");
return 0;
}
Ctrl+S，关闭；- 使用编译器编译（如GCC）：
gcc -o helloworld.exe helloworld.c；
- 运行：
helloworld.exe，或者./helloworld.exe。
于是我们就见到了helloworld.c和stdio.h两个文件。至少到这里，一般人都会有的想法：编写自己的程序用.c后缀，使用系统预定义的函数用.h后缀。为什么不能反过来呢？理论上可以。不过由于这已经形成了约定俗成的习惯，随意地违反规则，可能造成意料之外的结果。
接下来，按照大众称呼，将.c文件称呼为源文件source file，.h文件称呼为头文件header file。何为源文件呢？程序是由代码编译生成的，代码是程序之源，因而代码又叫做程序的源代码；源代码中的文件自然而然地便可以称为源文件了。那何为头文件呢？浅显易懂的理解方法是，.h文件作为include预处理指令的操作对象，一般都是随预处理指令放在文件头部位置的。（C语言中代码功能与书写位置是有关的；作用域为定义位置开始向后，所以需要的功能最好在一开始就引用。
在上文所提到的文章中，作者表示，由于include预编译指令的实际作用是将目标文件直接复制到当前文件的同一位置，所以文件到底叫啥，有什么后缀名都无关紧要，因为文件名在include预编译指令中必须明确指定。一开始我还在这踩了个坑，以为头文件中函数的实现只能在名称对应的源文件中查找，直到我试了一下。。。发现实际上至少在Visual Studio中，只要是在解决方案资源管理器中添加了的文件，都算是源文件，即使名字不对应，后缀奇怪，也不会影响函数实现的搜索，平时常见的头文件和源文件命名对应的目的只是为了方便开发人员寻找函数的实现代码。换个说法，就是MSVC会在编译时把添加到项目资源管理器的文件都扫描一遍，生成对应的目标文件（符号表）。即使后缀改成exe，只要没从解决方案中排除，照样编译给你看
寻找的两种不同的库文件（Windows下的.dll，Linux下的.so；Windows下的.lib，Linux下的.a），依次对应的是动态编译和静态编译两种各有优劣的编译方法。在此不做展开，关于这个内容的博客在搜索引擎上还是很好找的。由于了解尚不够深入，目前还不清楚源文件的有无是否影响动态编译——反正静态是肯定不影响的：编译器往往提供了其C标准实现（有多种，如GCC的glibc，BSD的BSD libc，Windows平台下的MSVC Runtime等等）的静态编译库，而不提供其实现源码。（从某种程度上来讲实现了对源码的保护）
但是在最简单的Hello World例子中，我们是无法找到stdio.c这个文件的。因为往往编译器都提供的是静态库，如上一段所说，原因为何我也不清楚。。
由于Windows下的MinGW采用的C标准实现是MSVC的，因而在编译程序时，所需要的函数实现都是从MSVC对应的静态库里提取的。这个静态库一般是libmsvcrt.a，使用strings工具可以看出其中存在printf字符串，可以间接地表明其中含有printf的实现。顺便了解到Windows下与grep对应的命令是findstr
由include的原理所牵扯到的是，“所include的文件一定要是头文件，而不能是源文件吗？”这样一个问题。这个想法很好：把源文件复制到待引用文件的头部的话，相当于是只是把函数的定义换了个位置写，然后用编译器命令复制过去，在理论上是行得通的。然而若是亲自实践的话，会发现编译器报出符号多重定义的错误，即实际上并不可行。
这个思考方式忽视了一个问题：打开任何一个现有项目的的头文件查看，里面都是只有函数的原型声明的，没有任何实现代码。上面也有提到，编译器会自动到所有指定为源文件的文件中寻找函数的实现，来试图在链接过程使这个函数具体化。那么如何实现寻找呢？在对源码直接进行搜索的基础上进行改进，把对源文件的词法和语法分析的中间结果记录下来，也就是可能会听说过的.obj文件，里面就有编译器可以识别格式的文件信息，包括定义的变量、函数等。再把函数名字相同的函数寻找出来（由于C语言是面向过程型的语言，没有重载特性，故没有函数签名一说），作为函数声明的实现。也就是说，可以理解为，编译期先将源文件解析为一一对应的一系列“符号集合”，然后在“符号集合”的并集里寻找匹配的函数实现。那么，上面的问题就好解决了：如果include了一个源文件的话，声明引用的文件中会出现被引用文件的代码，这些函数被定义了一遍，放进该文件的符号表里；同时由于被引用的文件被视为了源文件，该文件自身也会有一个对应的符号表，把文件里的函数定义一遍。由于这个“并集”并不会、且出于严谨的目的也不能自动合并命名重复的函数实现，因而在链接阶段，链接器将不知道该采用哪个实现，直接报出多重定义的错误。
如果我不把被include的文件添加至项目呢？
这个更好回答，你告诉编译器这个不是源代码文件，编译器就会直接在词法分析预处理的阶段报错。需要的文件“不存在”（因为你告诉编译器不是这个文件，而它又找不到其他满足条件的文件），词法分析无法进行。
而函数的声明和定义就不一样了，声明是针对编译的过程而言的，为的是向语法分析器确认该函数的用法。至于该函数到底有啥用，语法分析器不管，因为它不需要关心自己所处理的句子的内在含义的问题，只要句子“读得通”（符合文法）就行。所以，函数的声明是不需要写入到符号表的，相同的声明可以在不同的源文件中同时出现。这个时候，头文件的作用就显现出来了：能够规范简洁而统一地对需要引用的同一（批）函数进行声明。这个功能还可以扩展至所有声明性的工作，包括宏定义#define、C++的类定义、结构体以及枚举类型的定义，等等。但凡涉及到实体化的工作，即使是变量声明，也不能放在头文件中，因为只要有实体的对象都会被添加至符号表，造成重定义的错误。
总结如下：
.c文件里写代码（放实体），.h文件里放声明（说空话）。因为口说无凭,立字为据嘛