« 如果从头开发新的 3d engine | 返回首页 | 写了一个 proxy 用途你懂的 »

再谈 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 这样的构建工具自动化进行。具体实现我就不列出了。或许不久会新开开源项目实践一下。

云风 提交于 April 12, 2011 08:41 PM |

Comments

真能够折腾的 不过还挺不错的 现在做优化呢 没没时间弄 有时间交流一下!

Posted by: 北京最好的隆胸医院 | (16) May 19, 2011 10:03 AM

C语言模块化还需学习学习..........

Posted by: 红球藻 | (15) May 4, 2011 03:04 PM

学习了啊，呵呵。有点复杂啊。风的博客，欢迎指导www.feng521.com

Posted by: 风的博客 | (14) April 30, 2011 04:15 PM

深入一种语言去编程，云风在这方面的确高人一筹。

Posted by: thinkdancer | (13) April 25, 2011 11:29 PM

C的模块化程度很高啊，你看看php里dba的实现，都自动化了。。 我之前也写过一个网络引擎，模块间引用只要一句extern_module(xx) 不过确实让新人不好学。

Posted by: vical | (12) April 21, 2011 04:15 PM

C的模块化程度很高啊，你看看php里dba的实现，都自动化了。。 不过确实让新人不好学。

Posted by: vical | (11) April 21, 2011 04:12 PM

看看啊，不错啊，讲解的很到位啊，但是风还是不理解，毕竟太专业

Posted by: 风的博客 | (10) April 21, 2011 09:51 AM

经典的编程语言c！

Posted by: 广州废品回收 | (9) April 19, 2011 03:34 PM

嗯，昨天晚上匆匆的读了一下，草率的写下了评论。今天晚上又细细的看了一遍，可以肯定的说喜欢C语言的同学有福了。:)

Posted by: 涛 | (8) April 13, 2011 09:58 PM

__declspec(dllexport)，程序启动的时候去爬一遍导出的函数，名称符合约定的执行一下。

Posted by: Anonymous | (7) April 13, 2011 11:01 AM

我觉得是快速开发的一种趋势，减少配置（依赖也是一种配置），不完全是自动化生成代码，而是一种规范，ROR以及Spring现在都是这样做，只要掌握了规范，就能很容易的理解这台规则，也减少学习成本。

Posted by: mikecool [TypeKey Profile Page] | (6) April 13, 2011 09:57 AM

用objdump导出的符号生成模块初始化代码，真是个好方法啊。不过如果模块之间的初始化有依赖或是对初始化顺序有一定要求，是不是要在这里加一套排序规则？（您知道的由于种种原因这种情况在现实中经常出现。） btw: 是不是做久了都会对自动生成代码很上心？ :) 因为我们经理也是这样，只不过我们用到的代码生成不管是功能还是实现上都很简陋。

Posted by: 楼兰 | (5) April 13, 2011 12:30 AM

简短回复一下，不多解释。 dlsym 是运行时取得动态库内的符号。而这里是在编译期就需要得到符号信息。然后生成模块初始化的代码，并参与链接。 这个早于链接环节。我不清楚 gcc 的 linker 如何取出依赖以及导出的符号。不过如果是在链接的时候取得就已经晚了。 这里不用动态库，是我的项目经验告诉我的。不想过多解释。原文中已经提到过了。 无论用何工具不重要。用工具提取出符号，并自动生成初始化代码才是重点。我认为这比任何宏技巧(C) 或 template 技巧(C++) 或代码模板生成器更好。

Posted by: Cloud | (4) April 12, 2011 10:39 PM

armcc link后可以同时导出符号表，gcc似乎应该也可以，并不需要objdump

Posted by: kraft | (3) April 12, 2011 10:21 PM

>我们可以使用 objdump 来分析编译好的 .o 文件。比如有一个模块 foo ，实现在 foo.c 中。objdump -t 可以得到 .o 中引用以及导出的符号。 可以使用编程接口，dlsym()。

Posted by: bitstream | (2) April 12, 2011 10:18 PM

我觉得折腾这种玩意，还不如弄一个强大的代码阅读工具，给程序员一个好的环境阅读、运行代码。让程序员更快更深刻的熟悉所要面对的业务领域。程序员们之间多交流，多讨论，而不是一直想让他们独立工作，然后合到一起就可以正常工作。我觉得好的团队，就是每个人都知道别人在干什么，时间长了之后完全可以互换岗位。

Posted by: 涛 | (1) April 12, 2011 09:51 PM

Post a comment

非这个主题相关的留言请到：留言本