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

一介村夫

原帖由 converse 于 2009-10-27 11:33 发表
不认为,加前缀不仅在于解决命名冲突,而且还可以知道函数所属的模块,是很好的编码风格.类似pthread的API都有前缀,类似其他的很多库都是这样做的.

加前缀是一个好办法，但是会暴露很多东西。
所以我说include是一个折中方案。
考虑如下情况：
你做一个大型动态函数库，不采用include的方式会暴露很多内部函数，而这些本来不必要暴露的函数可能恰好跟调用你函数库的程序所调用的其它函数库中的函数重名，这也会给连接带来麻烦。

一介村夫

原帖由 koolcoy 于 2009-10-27 14:09 发表

加前缀有什么问题？
c++的namespace，java的package跟前缀有实质的区别么？ 就我看来，前缀唯一的问题就是在写代码的时候繁琐一点，只要有个好的代码编辑器这也不是大问题。

一个项目的头文件可以分成两种 ...

你以为头文件里不写，动态库里的函数就不可见了？
掩耳盗铃！

一介村夫

先理解一下我说的是什么，好吗？

一介村夫

凡是反对include .c（这里特指将一个大的.c文件拆成若干小文件然后包含的方法）都给个解决方案出来：

你做一个商业函数库供别人使用，如果里面包含可见非公开函数，你怎么能保证你的用户在连接你的库和其它另一具有同样特征的函数库的时候绝对不会发生冲突？

拿不出万无一失的解决方案就别吐我，先吐自己吧！

一介村夫

原帖由 shan_ghost 于 2009-10-27 15:05 发表


把一个大的.c文件拆成若干小的 .share 文件，然后 include xxx.share 行不行？

你们谭派弟子就是想标新立异，也换个不那么容易令人混淆的方式行不？

咬文嚼字有意思么？
你的.share和我说的.c在含义上有什么不同？
实际上，我可能更多地用.inc。

一介村夫

原来C语言的设计者和标准制定者们都不如本版的大牛们脑子清楚见多识广。
别忘了，存在即是合理，存在的东西总有它存在的道理，不是人家的疏漏，而是你自己站得还不够高。

一介村夫

原帖由 koolcoy 于 2009-10-27 15:09 发表

汗
你以为动态库里看不见就把函数的机器码搞不出来啊

我说的是连接的时候不会给用户带来困扰。
好好读帖！

一介村夫

原帖由 shan_ghost 于 2009-10-27 15:14 发表


那么，这种.c/.share/.inc，又和带实现的.h有什么不同？

扩展名用.c，在有些编辑器下可以自动语法高亮，这就是好处。

一介村夫

原帖由 koolcoy 于 2009-10-27 15:15 发表

加前缀会吗？

你能保证你加完前缀后就能不跟任何函数库里的所有函数重名吗？

一介村夫

原帖由 shan_ghost 于 2009-10-27 15:18 发表


扩展名用.h，在有些可以自动语法高亮.c扩展名文件的编辑器下面一样可以语法高亮，而且还遵守了程序界的基本道德，这更是好处。

“.h中不带函数实现”就不是约定和基本道德了么？