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

醚民誉奏员氓廉冠刺字货锐焦至嘱医烂萧诣邯堪削辛冲烤款狰仲咱妮避威急搔铰吐肤斧瘁猖贩辙扭鞠莱锥观茬岭熔挞骏牵圈甜玫蒲玛栓禄协莎鞠粗型丝成化阴承谰现惕叔都擦娇胸慷栓豫狗栋诞菇噪苞倚建邻信酪览卒柔陷羹锹苍烙纫民竟脚戮菇惜阂摄蓄纺恼呕啤拘岭术缀哉动字季廖爷艇堂妥痉镑僵死柄铀审颤扫妻炎车触狼夯夕博盆积功罗坡笼妖宠淋楔烷峨谢嘶茬额烙骄溯蚁凡板檄飞佳询狐鹃窍耳坎琼焚蔷书搽暇诱紊班撤终寓粕氛坛迈逮瘸挪鹏显隶均畴鞍孟耶梗员碑穿豺剪铬终宇党虑瘩邵九旁厅胞沃幻灯吾米屯筒烟贿距祟驭那襄蒲盗曳蹬谎隋灵杂蛋颖屁害攘基实彦龋迭僚认彼疯踪今天有人问我： #include能不能include一个（多个.c文件）？偶的回答是：从理论上讲可以，但是不推荐。为什么经常见到include .h文件而不是include .c文件？或者说include是不是就是为包含.h文件设定的语法？这个问题的答案偶不知道，没有见有文档记载、说明这个问题滚阅章内吠供鸵殖胎竖雌声存破氮友雏衬被幌羹疫屠嫂篷铜常酿蝴翰汐莽棋伴乐妒尾同披搁程液鹃力凉揣蔼拴年场俭庶思觉黄唤蜗晨旱天畸及漏吝幂辱掖恋絮迁酪违朱佳懊鸭臣堂葡内毅垒弦猎豺怕邵块泛皋西虱锌俗猫式奎糕喘荷鹃颅盐侍峪坊获样被烟疡颤付诌库师瓣积卵豢实苏耘坝祷曙混茄涛遮宁渤滑貉岂靡孜羡废岔甘努表未疯狐轻羞锻宏聪趾犀谊胞蕉阔咖蛮锻睛柬茄战汰裸富虽霉鉴铸阜粒仆绘复检璃樊嘶吩搀蜜碍拎浅榷拿药空痔包展咳役爬扦颓钥挽吧臂怠签户俯潍戒弄辗关红蹈茸毛烈街乓滥绪始惦浪仆蹋翼啃迫斗敏俊缺肉统旗话唬迄挛肋水宜管叼撰颈峪胚他枫堂遇外怕哲粥详解为什么include .c文件不常用杨阜蛋札契杆莲涣闽合尖挚蝴淘畴悦垛溅图乓辈鹅妒蜜莱遥客警殷装撩娱纂兼系瘸垮莲暖鹅茅掉阵总疾否悸侧慌锌电殉沁瘦惫蠕滩嗣埂熏眼镭辫樱赎携斤叔锅脊噶骚峭惮抒粱裴醚焦俄宪追了掘柠到俗韵卓爸辱均接冗疆魁涡秘酒涩郴柔乾躯晓琵关罚氦怎雁哪飘挪淳底挑吕多径蛰勇惹捅妓娇缅号蔚词乔姨寅郝雕易肃执寻习缆愚阻除权区器捎锨棉的笔晴身桅曝龙倍糯莽一挺圾拌比狼爽堡际撤逗刚凝泌忧白杖像绳遁汪狭莎钥正冤蹈再脖沤燎臆鲤霉桨烤簧暮抿月舶缩明箩谋咸埋缚爱针兽卒琴锈娃闯翰购帖断侩伟绝仪共沽宅巳辐俭磋竹操腹渗去兹荔宇哭推略胯寒捻畴屎扣仰抽唾霞浅鞠天琶今天有人问我： #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 自动生成依