以其昏昏，使人昭昭？

蔡万钊

有的人只在乎写出正确的程序，而有的人在乎写出漂亮的程序

OwnWaterloo

pmerofc 发表于 2012-08-01 20:40
我个人的感觉
你和村夫的观点有细微的差异
村夫认为蔡的方案不是每个编译器都适用
你则不认为蔡的方案根本不是针对这个问题的

我也怀疑是这样。也怀疑是村夫没注意就被蔡拉跑题了。拿不准。

所以从一开始我就说村夫的意图我不完全了解。但代价/可移植性这点应该没理解错。

蔡万钊

村夫的问题是这样的：

a.c 和 b.c 构成一个模块，比如 libmisc.(dll/so)  ,  都要使用一个相同的函数, 写在 c.c 中，但是这个函数不想暴露给除了 a.c b.c 之外的别的模块，哪怕没有提供头文件，也不想让人在导出表上看到.

这个时候
村夫的做法是：
只能是  a.c b.c 不再拆分，用 d.c 把 a.c b.c c.c include  进来，把 a.c b.c 需要用的函数写到 c.c 里，并且使用 static 修饰。

为什么 要这么做而不是写一个 .c 呢？ 因为 a.c b.c c.c 单独都很大，何况是合并成一个文件。为了保持每个文件比较小而这么做。


其实对于这个问题 gcc 提供了一个扩展，我的意思是，如果你恰好使用的是 GCC , 那就可以定义 visibility 属性。继续拆分， a.c b.c c.c

把 c.c 的 static 修饰改用 visivility 属性。

编译后的 c.o 符号还能被 a.o b.o 继续访问。

a.o b.o c.o 合并成 libmisc.(dll/so) 后， c.o 里的符号就不会被导出了，就像本来就是 static 一样。


如果使用的是 VC 编译器，好像使用 DEF 文件也能做到。

我确信其他的编译器应该也能提供相应的功能，如果没有的话，那使用 村夫的办法也不失为一个办法。
但是最好把后缀该一下，让别人一看就知道这是用来 include 的，不是独立的编译单位。

如果只为了编辑器高亮，那我只能说，这是编辑器的问题，不要用整个工程去迁就一个编辑器。
何况就算不是 .c 扩展名，虽然默认没有高亮，但是合格的编辑器都提供手工设置高亮模式。

OwnWaterloo

蔡万钊 发表于 2012-08-01 20:29
那是编辑器的问题。

编辑器或许对你来说不是问题。就像非GCC/VC下应该怎么做对你来说不是问题一样。

蔡万钊 发表于 2012-08-01 20:30
有的人只在乎写出正确的程序，而有的人在乎写出漂亮的程序

同样，对其他人来说漂亮的程序，在你这里可能就会沦为正确的程序而已。



是不是问题，问题有多紧急；什么是漂亮，标准是什么？没有公认的说法。
为什么一定要以自己的标准衡量他人的选择？

OwnWaterloo

蔡万钊 发表于 2012-08-01 20:44
如果使用的是 VC 编译器，好像使用 DEF 文件也能做到。

我确信其他的编译器应该也能提供相应的功能，如果没有的话，那使用 村夫的办法也不失为一个办法。
但是最好把后缀该一下，让别人一看就知道这是用来 include 的，不是独立的编译单位。

如果只为了编辑器高亮，那我只能说，这是编辑器的问题，不要用整个工程去迁就一个编辑器。
何况就算不是 .c 扩展名，虽然默认没有高亮，但是合格的编辑器都提供手工设置高亮模式。

我相信任何编译器都有这个功能 —— 控制（链接目标的）导出符号。
我也相信大部分编辑器都有办法去设置高亮 —— 不支持的编辑器就可以丢了。


问题是：你得去找控制导出符号的方法以及设置高亮的方法。
这对你来说可能不是一个很迫切的问题，但其他人不一定这么看。

有一劳永逸 —— 无论什么编译器编辑器都凑效 —— 的方法，代价只是破坏一个习俗。
也许你觉得这个习俗是不值得打破的。 同样，其他人可能觉得打破这个习俗的代价比折腾各种编译器编辑器代价更小。

同样，也不是所有人看到.c就会认为这是独立的translation unit。

仅仅是在某些问题上的权重与你不同而做出了不同的选择。

OwnWaterloo

回复 3727# 蔡万钊

我也不清楚是否准确理解了村夫的要求。所以下面就当是我自己的要求好了：

1. 链接目标(so/out/dll/exe...)由p.c, q.c, r.c, ...构成。

2. p.c, q.c, r.c, ...里有各种的私有函数（仅仅在该.c文件内使用的） —— 这里是很习俗的做法。
我记得村夫原始需求里那些函数只在某一个translation unit里用，不存在跨translation unit。否则我都会倾向控制导出符号以避免那些函数体重复了。
村夫的原始需求里只是没有提多个translation unit，以及下面的：

3. 这些私有函数都（应该）是static linkage，以避免潜在的整个链接目标出现重复的可能性 —— 这也还是很习俗的做法。
根本就没有DEF/visibility出场的机会。


然后与村夫类似的问题出现了： p.c, q.c, r.c中的某些文件过长，浏览不方便。并且假设无法重构。

依然有不违法习俗的方法：折腾编辑器。 搜索啊、折叠啊、书签啊什么的。
为了避免折腾编辑器， 可以利用C语言提供了一种就地展开其他文件内容的标准机制： include。
用include将那些static拆分到p1.ext, p2.ext, ...  然后用 p.c包含它们。

进一步，关于扩展名ext的选择。 .c是一种打破习俗 —— .c被认为是单独的translation unit —— 但可以避免折腾编辑器的做法。