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

群雄逐鹿

原帖由 albcamus 于 2009-10-29 11:13 发表


嗯，那你就使劲include c好了。 C语法同时还支持函数内任意goto，你也多用好了。--- C语法允许的事情很多， 你很自由的。

PS，你知道给辩论对方 总结一个心理上的原因， 让我想到什么了吗？

无非就是找一个故事再次总结一下对方，呵呵~~

比较反感的就是不分情况 “绝对” 的这个不好那个不好，goto不好，也有适用的地方，你linux玩那么好，当然比我明白

koolcoy

原帖由 群雄逐鹿 于 2009-10-29 10:30 发表


我约摸了一下，对#include .c绝对排斥的有几类：

1. 过分追求完美的
2. 教师
3. 项目经验太少，只弄过几个sample之类的
4. 对可维护性视而不见的
5. 觉的只有 include *.h 才算正统

// This file exists to help compile the essential code of
// JavaScriptCore all as one file, for compilers and build systems
// that see a significant speed gain from this.

人家是为了提高可维护性么？

shan_ghost

呵呵，昨天写的个回帖，本来不想贴出来了。不过看到很多被夹的 “非此即彼” 的黑白脑袋，感觉还是有贴一贴的必要

原帖由 prolj 于 2009-10-28 12:04 发表
设计相当重要，代码量大并不能说明什么，我把一个十万行的模块消减到1W行了。
不知道村长的项目为什么include c，但是，我想表达，实际工程中要尽可能的简单，因为每一行代码都是自己日后的负担，该用的手段就 ...

我也会用，哈哈


比如以前遇到过一个项目，把所有.h文件都集中放在一个目录——这情况俺改变不了。
那么这时候，如果遇上村长的情况，俺估计也会直接动用 include .c或者 include .inc之类手段，谁让他们的源码管理那么水呢


窥探系统的内部实现，通过奇奇怪怪的手段实现功能，几乎是每个有一定经验的程序员都干过或正在干的——根源一般都来自愚蠢的总体设计或意料之外的特殊情况或程序员自己对相关领域的不了解。

不过，一般这种地方，俺都会重点测试，并且加上这样的注释：
//!!!WARNING!!! 吧拉巴拉写一堆说明
//!!!HACK!!! 吧拉巴拉写一堆理由
这样以后有了时间，或者有了新的认识，只要搜一下三个叹号就可以回来改掉。


总之，某些做法是正常的，某些做法是异常的。也许知道了更多东西，异常的做法就能被更好更规范的做法替代，也可能找不到替代办法，或者发现异常做法其实就是业界在类似情况下的标准做法；甚至是虽然有替代办法但不想支付改变的代价，因此仍然坚持了异常做法，这些都是正确的处理方法。

关键问题就是：必须要知道什么样的做法才是正常的，必须训练自己，保持对“坏味道”代码的敏感。
如果丧失了这种敏感，甚至是从一开始都没训练出这种敏感——那么这种程序员就太可怕了。



具体到这个例子上，include .c就是最典型的“邪恶”用法；或许在某种情况下迫不得以要用，但记住这种做法是必须严格控制扩散范围的、甚至是见不得人的、贻笑大方的。

再次强调一次，include .c并不提供任何功能。include .share .inc .c_part 等等都同样能达到同样的效果。

正如村长之前所说的，不用.share而用.c，仅仅是因为.c可以自动在编辑器中语法高亮——这就是抛弃.h这个一般规范换来的唯一好处。

当然，如果知道这种做法肮脏、邪恶，并且知道要严格控制这种做法的使用范围，那么在这个大前提下，它并不会造成太大太恶劣的影响。
那么，这时候，节约一个点开自己的编辑器配置菜单，把.share或.c_part也关联为c语言源代码的沉重代价，破坏一下关于.h的一般约定，当然也不是什么大不了的。

——这就好像你路过某美女身边，无意间顺着人家衣领子看了进去，大大的暗爽了一把：这种行为虽然不对，但男人嘛，理解。
——可是如果以后你天天乔装改扮动用各种先进技术器材去窥探女澡堂，那就不能不说阁下的心理出现比较严重的问题了。

IOIOC

在某 c 里 include 某某 c，则 某某 c 里的函数对外不可见？ 村长是这个意思吗？

chiyiangel

老谭的书  说白了给你考证 有点用~~~ 反正我看到里面东西 还是C89 的 我就不想看下去了

emacsnw

村长的问题，除了使用特定命名规则，无解。我觉得这也正是为什么C++要引入namespace的概念。

不过内部实现全部用static并且include .c绝对是不妥当的，你改动任何一个很小的被include的piece，整个代码都要重新编译。如果真像村长说的数万行，这个编译时间开发时绝对不能接受。

更重要的是，如果这些代码块只是最终被一个大的.c整合在一起还好。如果这些实现需要被多个村长说的对外模块include的话，目标代码是会有大量重复的。为了达到静态链接对外隐藏而作出如此多的牺牲非常不值得。

综合来说，采用命名规则才是王道。

converse

呵呵,而且我觉得他说的那种不能保证不会有命名冲突的情况太绝对了.加个前缀真能解决大部分命名冲突问题了,一般前缀是公司名,或者库名,我不知道这个世界上这些重名的有多少?

dorke

问题的本质我觉得就一个：解决问题，只要能解决问题，没有什么好坏了！

也许这个方式最好，但是这个方式最快的解决了问题或者最平衡的解决方案，那么就OK了。谢谢楼主教了我一个方法！

此刀虽好，但是我不到万不得已，我不会用，因为我只用自己的剑。

一介村夫

原帖由 emacsnw 于 2009-10-29 13:47 发表
村长的问题，除了使用特定命名规则，无解。我觉得这也正是为什么C++要引入namespace的概念。

不过内部实现全部用static并且include .c绝对是不妥当的，你改动任何一个很小的被include的piece，整个代码都要重 ...

你部分地理解了我的意思，但不是全部。

一介村夫

原帖由 converse 于 2009-10-29 13:56 发表
呵呵,而且我觉得他说的那种不能保证不会有命名冲突的情况太绝对了.加个前缀真能解决大部分命名冲突问题了,一般前缀是公司名,或者库名,我不知道这个世界上这些重名的有多少?

是不多，但是就怕你的公司叫A，你的模块叫B，你的函数是C，你的规范是A_B_C；而别人项目叫A，模块叫B，函数是C，规范是A_B_C。
举这个极端的例子只是想说明，世界上没有统一的命名规范，无论怎么命名都难保不撞车，留有撞车隐患的产品都是不合格产品。
为了不使用自己感觉恶心的写法而留下潜在隐患，得不偿失。

[ 本帖最后由 一介村夫 于 2009-10-29 17:13 编辑 ]