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

lixinwei1985@si

什么时候老谭的名字上能打上方框阿

ahocat_cu

看来我们说的不是一回事。
考虑这种情形：
一个巨大的程序由几个大模块组成，每个大模块都有几万行代码，模块内部存在复杂的彼此间调用关系，如何使得最后的产品在模块间的相关性最低？
A模块中有一个Open ...

说的也有道理。对于经验丰富的程序员来说，只要自己有能力驾驭，也不能算错；这应该归到“奇技淫巧”之类的。
但是谭的书是面向初学者的，教他们去 include .c 恐怕就不合适了。

[ 本帖最后由 ahocat_cu 于 2009-10-27 08:55 编辑 ]

prolj

村长的手段真特别，我用另一种手段，函数声明用XML描述

光速

include .c具体有什么不妥之处？想了解一下.

kouu

我觉得这个事情还是有两面性：
一方面，按照惯例，.c总是被当作实体进行编译，并生成对应的.o文件的；.h则不被单独编译。include .c，如果不小心的话，可能一个.c的内容被编译进多个.o文件中，导致link失败。 所以，通常并不会include .c。
另一方面，上面这个惯例完全是可以打破的。如果一本书总是把写.c、include .h标榜为标准，则看书的人可能不太会去问为什么，以至于学了很久还不能理解include到底意味着什么，只知道应该是这样用的罢了。

谭浩强的这本书没怎么看，上下文联系不上，不便说好与坏。

shan_ghost

原帖由 光速 于 2009-10-27 09:21 发表
include .c具体有什么不妥之处？想了解一下.

在 .h 文件里实现函数有什么不妥之处，include .c就有同样的问题；或者说include .c能解决什么问题，在头文件里实现函数就也能解决什么问题。

而且，.h里声明函数虽然会导致某些特定问题，但有经验的C/C++程序员一看到就可以有心理准备，知道该如何对待；而include .c文件，出同样的问题就会隐蔽得多。


再次，对于一个C/C++程序员来说，凡没有声明在 .h 里的函数，都是模块的内部函数；那么只要保持本模块内部的同步，这个函数可以改名、改接口、改返回值——改它的内部行为就更不用说了。

但是，一旦include了.c文件，那么这种保证将荡然无存。对新接触这些include了.c文件的工程代码的人来说，这个软件必然处处都是炸弹，任何地方都不敢碰不敢摸，否则它就会在完全八杆子打不着的地方爆炸——然后哭笑不得的发现，它把你的内部实现include进去了。

这是对最基本的编程规则的挑衅，也是对最基本的编程理念的颠覆。

一介村夫

原帖由 converse 于 2009-10-27 08:42 发表
账号被盗了?

一不小心进了你的地盘。

一介村夫

原帖由 ahocat_cu 于 2009-10-27 08:48 发表


说的也有道理。对于经验丰富的程序员来说，只要自己有能力驾驭，也不能算错；这应该归到“奇技淫巧”之类的。
但是谭的书是面向初学者的，教他们去 include .c 恐怕就不合适了。

这个想法是我在看别人的汇编代码的时候想到的。

converse

这个挺在理.
我想谭的书如果真的是这么写的话,恐怕考虑没有那么多,那么就只有两种可能了:一种是笔误,另一个是他不知道头文件是干啥用的....

一介村夫

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

以前做项目的时候，几个人分头写一个大程序的不同模块，结果整合的时候发现在不同模块间存在很多同名函数。
懒人的解决办法是加前缀，把函数名变成"张三OpenFile"或"模块A_OpenFile"；但是我觉得更好的办法是对其它模块隐藏自己内部的函数。
要实现隐藏，就不能使用把文件拆小分别编译的方式，而include就成了一个折中方案。