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

converse

不认为,加前缀不仅在于解决命名冲突,而且还可以知道函数所属的模块,是很好的编码风格.类似pthread的API都有前缀,类似其他的很多库都是这样做的.

一介村夫

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

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

koolcoy

原帖由 一介村夫 于 2009-10-27 13:09 发表

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

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

一个项目的头文件可以分成两种，一种是供外部使用，另外一种是供内部使用的，供内部使用的头文件在发布的时候不要发布就行了，犯不着include .c

shan_ghost

a.h　<——————— b.h
|                                     |
a.c                               b.c
|                                    |
a1.h a2.h                     b1.h b2.h
  ｜                              ｜
   —————————
                   ｜
                   c.h

如上，一个很复杂的库(以3D游戏举例吧)，对外提供两个头文件（a.h 和 b.h），配合a.lib 和 b.lib，已经提供了全部可公开接口。

其中，a.h提供了3D加速算法，b.h提供了2D加速算法；

a.h提供的算法，内部被分解后，使用a1.h 和 a2.h提供的一组正交算法实现（比如矩阵、坐标变换等等）；同时还必须使用b.ｈ提供的一些2D接口；

b.h提供的算法，内部被分级后，使用b1.h 和 b2.h提供的另一组正交算法实现（比如颜色空间变换、图像的高速缩放等等）


最后，无论是３Ｄ接口还是2D接口，最终都要根据硬件选择不同的基本指令，而这个工作由c来完成。


最终效果就是： 用户仅仅看到了ａ.ｈ和b.ｈ（实际使用时，include ａ.ｈ，则 b.ｈ就会自动被include进来），可以完成各种2d、3d计算任务；而内部的a1.ｈ、a2.ｈ、b1.ｈ、b2.ｈ，他们统统看不到；更底层的c.ｈ就更不用说了。

不仅如此，虽然a和b都包含了c，而且ａ最后又包含了b；但a1和a2提供的接口名字完全可以和b1、b2模块内部的名字重复而不会导致任何问题——只要保证ｂ.ｈ没有ｉｎｃｌｕｄｅ　ｂ１.ｈ/ｂ２.ｈ就可以了。


PS：

1、注意在c/ｃ++中，在.ｈ文件中include一个.ｈ文件，和在.ｃ/.ｃｐｐ文件里include一个.ｈ文件，含义是完全不同的。
在.ｈ中include就相当于public声明，这个被include的.ｈ文件就必须向其他“能访问到include它的那个.ｈ文件”的用户公开；而在.ｃ中include则相当于ｐｒｉｖａｔｅ声明，被include的.ｈ文件对外部用户来说是不存在的。

善用这个特性，没有什么架构是非include .ｃ文件否则就表达不出来的。



2、对c/ｃ++编译器来说，一个文件的扩展名究竟是.ｈ还是.ｃ并不被它们关心——改名成 .ｓｈａｒｅ 也一样能正常工作。

举例来说，仅仅写一个.ｈ文件也能编译出.ｏ/.ｏｂｊ文件，只要你把函数实现也写进去就不会出现xx未声明的错误；仅仅写一个.ｃ而没有同名的.ｈ更是司空见惯之事。

说白了，用.ｈ标记头文件、.ｃ标记实现文件，只是为了有条理的组织代码而已。

所以，遵循这个规定，和遵循写程序要写注释、变量命名要有意义是一回事，仅仅是一个程序员的职业素养的体现，也是一个公司管理水平的体现。

[ 本帖最后由 shan_ghost 于 2009-10-27 14:31 编辑 ]

一介村夫

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

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

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

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

一介村夫

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

albcamus

include .c是极其丑陋的编码风格， C允许这样做，是完全多余的。

shan_ghost

原帖由 一介村夫 于 2009-10-27 14:44 发表
先理解一下我说的是什么，好吗？

尝试下 include  xxx.share 文件，看看能不能发现一片新大陆

一介村夫

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

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

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

shan_ghost

原帖由 一介村夫 于 2009-10-27 15:02 发表
凡是反对include .c（这里特指将一个大的.c文件拆成若干小文件然后包含的方法）都给个解决方案出来：

你做一个商业函数库供别人使用，如果里面包含可见非公开函数，你怎么能保证你的用户在连接你的库和其它另 ...

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

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