谭浩强的书我就不说什么了，居然教学生include一个.c文件

一介村夫

原帖由 langue 于 2009-10-27 00:58 发表
#include  本来就是多余。既然可以拆成小文件，链接器可以解析所有的符号，那又为何要拿来放在一个编译单元里？拆散了编译不是一样的嘛。

A.c要调用B.c里面的函数，在拆散的情况下，就必须把B.c中的函数暴露出来。

一介村夫

原帖由 langue 于 2009-10-27 01:04 发表


好维护就怪了，你修改其中的一个文件，整个 parent file 都要重新编译，拆散了编译就不会。

拆散就要声明原型，而有些函数只是在功能内部多次调用，根本没必要暴露给整个程序。

langue

这只能说明你的模块之间耦合度太高，是时候适度降低耦合了。

一介村夫

原帖由 langue 于 2009-10-27 01:16 发表
这只能说明你的模块之间耦合度太高，是时候适度降低耦合了。

我恰恰是模块之间没有耦合才需要对其它模块屏蔽本模块的函数。

langue

原帖由 一介村夫 于 2009-10-27 01:18 发表

我恰恰是模块之间没有耦合才需要对其它模块屏蔽本模块的函数。

这恰恰和你先前的说法相悖。

A.c要调用B.c里面的函数，在拆散的情况下，就必须把B.c中的函数暴露出来。

一介村夫

原帖由 langue 于 2009-10-27 01:21 发表


这恰恰和你先前的说法相悖。

这是对你说的，就是因为我觉得在没有耦合的情况下，向整个程序暴露模块内部的函数不好，所以才不采用拆散而是采用include的办法。

langue

模块内部函数应该是模块自己的事，与其它模块本来就没关系。static linkage 就可以了。

一介村夫

原帖由 langue 于 2009-10-27 01:26 发表
模块内部函数应该是模块自己的事，与其它模块本来就没关系。static linkage 就可以了。

看来我们说的不是一回事。
考虑这种情形：
一个巨大的程序由几个大模块组成，每个大模块都有几万行代码，模块内部存在复杂的彼此间调用关系，如何使得最后的产品在模块间的相关性最低？
A模块中有一个OpenFile功能，B模块中也有一个，但是两者完全不同，如果把程序拆散，就要分别暴露这两个函数，而为了使A模块与B模块的同名功能不冲突，就势必要对这两个函数的命名复杂化。
同时，考虑到命名的可读性，再考虑到nm的功能，如果采用拆散的方式，最后的产品就跟赤裸裸地站在别人面前一样。
当然，确实存在include方式使得编译不便的问题，但是这是一个取舍问题，当你不想让别人太容易通过反汇编读懂你的程序的时候，适当地多隐藏一些东西还是有好处的。

converse

账号被盗了?

baopbird2005

好像最近大家对老谭很关注啊