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

mb459

我是使用老谭的c预言书入门的，书很好，很强大，很透彻，何必苛求这些细节呢？

wangdan1600

花了半个小时，看完了所有回复。

不能说总结，我也见过有些源文件，偶尔有一个c文件9000+行。但我从来没见过include c文件的。linux还不够复杂么，也没见有包含c文件的。如P阿姨所说，10W行的代码可以优化到1W行，设计很重要的。

村长的话本意是这种方式是这个可以用的，但是村长也不鼓励这么用。可能实际遇到的问题比较复杂，不太好权衡取舍吧。大家最后差点把村长逼得以后代码非include c不可了

呵呵。原则上不用。

一介村夫

原帖由 JohnBull 于 2009-10-28 21:14 发表


无数人都教过你了！——使用正常的命名方案！——你认为“懒惰”的方法就是最简单、最直接、最精神正常的解决方案

项目开发规范不明确，一帮初级程序员不负责任地胡乱命名造成了名空间污染，不得以使用了 ...

你根本就没有认真看帖！
作为一个商业函数库，即使你采用了全球唯一的标准的命名方法，如果其中含有未公开的可见函数，那么当两个这样的库在一起连接的时候，后果是什么？你如何保证它们就绝对不会同名？
如果你认真地看了帖子，早就该明白我说的问题是什么。
为了避免出现这样的情况，解决方案之一（我现在只敢说之一，期望你这种“高人”能说出之二）就是用static进行描述，但是当模块的相关性非常高的时候，无法将整个模块的代码拆分成几个文件，当这样的模块代码达到上万行甚至几万行的时候，势必带来阅读和维护的困难！你如何解决？
牛人不是靠骂娘和讽刺挖苦出名的，是真刀真枪练出来的，光说几个狗屁原则有个屁用！
练点真活儿，也好让人服气，否则就不要酸葡萄了。

lanying_wzw

我感觉大家都误解村长的意思了，确实存在这种情况，a.o的公开函数虽然只被b.o，c.o调用，但是对d.o也可见了，楼主想解决的问题是a.o的公开函数只对b.o和c.o暴露，而对d.o不不暴露的问题，规范命名虽然可以不冲突，但是解决不了对不该暴露的模块也暴露的问题

群雄逐鹿

原帖由 prolj 于 2009-10-27 09:09 发表
村长的手段真特别，我用另一种手段，函数声明用XML描述

这个手段真变态。
不过总有一天会吃这个混乱的亏的，凡是企图统一更多接口的企图，最后都不过增加一种新的接口。

whelysee

慢慢明白你们所讨论的内容。实际上和本帖已经脱节。
而且确实有“误解逼迫”村长的意思，我觉得村长更多的是在举例证明include .c在适当时候的适当用法。

其实我觉得原作者说这句话的本意也并不是说include .c天理不容，或许他只是想说教初学者使用这样的方法是不合适的。

张三的《从郑州去北京》一书我就不说什么了，居然教学生步行从郑州走到北京。

我想对于刚刚学会走路，准备学习如何在城市之间移动的人，叫他步行肯定有坏处的，毕竟有汽车火车飞机。

步行只是不可取的，但不是无法达到的。  

而且万一出现下面的情况：汽车火车飞机骡子大马三轮摩托等所有的交通工具都不能用了……

whelysee

辩论就是这样，无论是正方还是反方，你都能从中归结出点什么。

wee0618

你们在说谭木匠么？

coneagoe

原帖由 一介村夫 于 2009-10-28 16:38 发表

你真的看明白我说的是什么了吗？

你这样include .c这个问题是可以预见的，跟你实际解决什么问题有冲突吗？
你想说其实大师都错了，你是正确的是吗？

trainee

我觉得潭老师不是特意的去教别人include .c
它是告诉别人include .c也是可以的. 它只是没说, "为了规范,最好不要include .c"

如果没有他无意\有意去include.c , 我还真以为include只能跟h. 他这样做,说明他间接告诉了你include的本质.

学c是个复杂的过程, 没有一个人只通过看书, 就能成为一个语言高手.所以不要太指责潭老师.

[ 本帖最后由 trainee 于 2009-10-29 09:13 编辑 ]