详解为什么include .c文件不常用.doc

今天有人问我： #include能不能include一个（多个.c文件）？偶的回答是：从理论上讲可以，但是不推荐。为什么经常见到include .h文件而不是include .c文件？或者说include是不是就是为包含.h文件设定的语法？这个问题的答案偶不知道，没有见有文档记载、说明这个问题。不过从语法角度讲，include的意思就是从当前位置包含另外一个文件，就象宏替换一样把当前行用另外一个文件的整个内容替换掉。从这点讲，include .c文件是可行的，c编译器完全能够正常处理。但是为什么不常见include .c文件？我想从两个方面可以得到一点解释。一就是，从设计角度上讲，源代码区分为.h和.c文件，是为了接口与实现的分离，实际上两者没什么本质的差别。.h文件提供接口，.c文件提供具体的实现，两者可以一一对应，也可以不一一对应，没有强制要求。一个.c文件做为一个模块的实现，有可能要跟其他的模块打交道，这个时候就需要include其他模块的接口(其他模块的.h文件)；而包含其他模块的实现(.c文件)是没有意义的、危险的。二就是从编译角度上来讲，make对同名的.h和.c之间提供隐讳规则的支持，就是说在makefile中不必显式指定一个.c文件依赖于同名的.h文件，就能达到显示指定这一依赖规则的作用。这个规则的副作用就是，如果.c文件中包含了另外的.c文件，除非在Makefile中显示指定这种依赖规则，否则make不会自动添加这种依赖关系。这样，很多时候被包含的.c文件改变了，原本需要重新编译的模块得不到重新编译(除非你手动删除对应的.obj或者执行rebuild)，这样的话对工程管理和排错都造成了很大的障碍。所以，我们不应该在项目中include .c文件，这样使用者出于直觉很难想到这里会有问题，增加了排错的难度。前几天偶移植一个国际知名大公司的代码就遇到了这个问题，耗费了半天的时间查看了全部的源码和makefile才发现了这个不常见编译现象。当然，那个公司的代码之所以这么做，是他认为这些代码已经很成熟了，不需要修改和反复重新编译。但它的做法确实对我的调试造成了很大的障碍。－－－－－谢谢[满头大汗]的提醒，偶又做了改动：删除线都是写的不对的内容。补充的是：即便是include了.c文件，如果修改Makefile，也能完成其依赖关系。这个帖子放的久了，就不删掉了。－－－－－ GNU Make Document 中的相关章节 －－－－－4.12 自动生成依赖在为一个程序编写的makefile文件中，常常需要写许多仅仅是说明一些OBJ文件依靠头文件的规则。例如，如果‘main.c’通过一条#include语句使用‘defs.h’，您需要写入下的规则：main.o: defs.h您需要这条规则让make知道如果‘defs.h’一旦改变必须重新构造‘main.o’。由此您可以明白对于一个较大的程序您需要在makefile文件中写很多这样的规则。而且一旦添加或去掉一条#include语句您必须十分小心地更改makefile文件。为避免这种烦恼，现代C编译器根据原程序中的#include语句可以为您编写这些规则。如果需要使用这种功能，通常可在编译源程序时加入‘-M’开关，例如，下面的命令：cc -M main.c产生如下输出：main.o : main.c defs.h这样您就不必再亲自写这些规则，编译器可以为您完成这些工作。注意，由于在makefile文件中提及构造‘main.o’，因此‘main.o’将永远不会被隐含规则认为是中间文件而进行搜寻，这同时意味着make不会在使用它之后自动删除它；参阅隐含规则链。对于旧版的make程序，通过一个请求命令，如‘make depend’，利用编译器的特点生成依赖是传统的习惯。这些命令将产生一个‘depend’文件，该文件包含所有自动生成的依赖；然后makefile文件可以使用include命令将它们读入（参阅包含其它makefile文件）。在GNU make中，重新构造makefile文件的特点使这个惯例成为了过时的东西――您永远不必具体告诉make重新生成依赖，因为GNU make总是重新构造任何过时的makefile文件。参阅Makefile文件的重新生成的过程。我们推荐使用自动生成依赖的习惯是把makefile文件和源程序文件一一对应起来。如，对每一个源程序文件‘name.c’有一名为‘name.d’的makefile文件和它对应，该makefile文件中列出了名为‘name.o’的OBJ文件所依赖的文件。这种方式的优点是仅在源程序文件改变的情况下才有必要重新扫描生成新的依赖。这里有一个根据C语言源程序‘name.c’生成名为