好吧, 看到标题你一定认为我犯了一个big mistake, 我没有遵循include .h标准范式去编写程序, 不过我还是想说说这里面的好处 :)
现在我们有一个需求, 想要编写一套事件库以便适应不同的平台(linux, freebsd … ), OK, 这里有一个显然的问题是我们需要一套抽象接口, 以便不同的平台都去遵循使用它们, 在不同平台下编译可以使用相应的.c文件, 我们需要建立抽象接口头文件, 但是如何去找到不同的实现文件那? 因为不同的实现文件需要在编译期指定好, 写在Makefile里做参数? 显然不够智能, 我们还是希望可以auto build. 于是我们想出了一套看似完美的方案, 为不同平台建立不同命名的头文件, 比如linux下使用 ev_epoll.h, freebsd下使用ev_kqueue.h, 不过这两个文件内部使用完全相同的接口定义, 一般来讲这没什么问题, 我们只需要在framework里根据不同平台include不同的header即可~ . 不过这里有个潜在的问题, 我们一旦修改了抽象接口定义, 不但要修改响应实现文件(这不可避免), 还需要级联的维护响应的headers, 这看起来很糟糕, 然后聪明的我们又想出来一个升级方案, 在这些不同平台的headers里面统一include一个global header(包含抽象描述), 我们拿着这套方案感觉很nice~ , 不过我们一旦修改, 仍然不可避免的去要修改global header, 虽然代价已经很小了~ :D
好了, 赘赘的说了一大堆, 开始进入正题, 我们能不能有什么办法去掉这个header, 因为这个header本质上没有存在的价值, 外部并需要看到他, 多个它放在那会让使用者头大不已, 请出我们今天主角:”include .c”, 我们先了解下include, 其实它并不在乎include什么东东, 只要语法正确即可~ , 那么利用这个特性, 我们直接include .c(相应平台的具体实现文件, 比如ev_epoll.c/ev_kqueue.c), 你可以理解为他们的代码被copy paste到include的位置, 然后我们不需要任何头文件的依赖, 也不需要为修改接口而相应去修改一个根本没有存在必要的header.
:D , 最后简单说下编译这样文件的过程, 因为我们已经include.c了, 所以我们在写Makefile的时候就不需要再去把这个.c文件填进去了, 否则容易出现各种声明,变量不存在的error, 调用include .c的文件会自己帮我们把它copy paste过去, 我们就不用操心了, 是不是很简单 :)
Have fun~