再谈 C 语言的模块化设计
去年谈过 C 语言对模块化支持的欠缺。我引入了一个 USING 方法来表达一个 C 语言编写的模块对其它模块的依赖关系。用它来正确的处理模块初始化。
现代语言为了可以接近玩乐高积木的那样直接组合现有的模块,都对模块化做了语言级别上的支持。我想这一点在软件工程界也是逐步认识到的。C 语言实在是太老了。而它的晚辈 Go 就提供了 import 和 package 两个新的关键字。这也是我最为认可的方式。之前提到的方案只能说是对其拙劣的模拟。确认语言级的支持,恐怕也只能做到这一步了。
在项目实践中,那个 USING 的方案我用了许多年,还算满意。之前有过更为复杂“精巧”的方法,都被淘汰掉了。为什么?因为每每引入新的概念,都增加了新成员的学习成本。因为几乎每个人都有 C 语言经验,但每个人的项目背景却不同。接受新东西是有成本的。任何不是语言层面上的“必须”,都有值得商榷的地方。总有细节遭到质疑。为什么不这样,或许会更好?这是每个程序员说出或埋在心里的问题。
那个 USING 的方案远不完美,它只是足够简洁,可以让程序员勉强接受而已。但其实还不够简洁。因为从逻辑表达上来说,它是多余的。一个模块使用了另一个模块,代码上已经是自明的。从 C 语言的惯例上来说,只要 #include 了一个相关的 .h 文件,就证明它需要使用关联的模块。光用宏的技巧很难只依靠一次 #include 就搞定正确的模块初始化次序。因为 C 语言并没有明显的模块概念。如果将每个子模块都编译为动态库可能能一定的解决问题(我曾经试过这种方案),但却会引出别的问题。细粒度的动态库局限性太大。
这两天我结合这半年学习 Go 语言的体验,又仔细考虑了一下这个问题。想到另一个解决方案。
如果我们能规范系统中子模块 API 的命名规范,或许可以借助编译器和相关工具来做一些 meta programming 的工作。
我们可以使用 objdump 来分析编译好的 .o 文件。比如有一个模块 foo ,实现在 foo.c 中。objdump -t 可以得到 .o 中引用以及导出的符号。
我们要求所有子模块中的 C API 都遵守一致的命名规范,假设用驮峰命名的话,foo 模块中的 Api 就看起来像这样 fooApi 。objdump 的结果可以轻易的识别出规范内的引用的其它子模块有哪些。然后生成一个类似之前提到的 USING 方法可以调用的初始化函数。自定义的模块初始化函数可以统一命名为 fooInit 的形式,当这个初始化函数存在,则由自动生成的代码调用一下即可。
整个过程可能比较繁杂,但很容易用 make 这样的构建工具自动化进行。具体实现我就不列出了。或许不久会新开开源项目实践一下。
Comments
Posted by: 北京最好的隆胸医院 | (16) May 19, 2011 10:03 AM
Posted by: 红球藻 | (15) May 4, 2011 03:04 PM
Posted by: 风的博客 | (14) April 30, 2011 04:15 PM
Posted by: thinkdancer | (13) April 25, 2011 11:29 PM
Posted by: vical | (12) April 21, 2011 04:15 PM
Posted by: vical | (11) April 21, 2011 04:12 PM
Posted by: 风的博客 | (10) April 21, 2011 09:51 AM
Posted by: 广州废品回收 | (9) April 19, 2011 03:34 PM
Posted by: 涛 | (8) April 13, 2011 09:58 PM
Posted by: Anonymous | (7) April 13, 2011 11:01 AM
Posted by: mikecool | (6) April 13, 2011 09:57 AM
Posted by: 楼兰 | (5) April 13, 2011 12:30 AM
Posted by: Cloud | (4) April 12, 2011 10:39 PM
Posted by: kraft | (3) April 12, 2011 10:21 PM
Posted by: bitstream | (2) April 12, 2011 10:18 PM
Posted by: 涛 | (1) April 12, 2011 09:51 PM