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

evaspring

村长大战众版主~   看高手论剑真是别有一番风味 ~

fera

原帖由 prolj 于 2009-10-26 23:26 发表
其实，是可以 include C文件的，而且，可以include def文件，当然，文件内容要不违法（C的法律）。

嗯

一介村夫

原帖由 evaspring 于 2009-10-28 10:00 发表
村长大战众版主~   看高手论剑真是别有一番风味 ~

很多人都是站在实验室的角度看问题，没有上升到工程的高度。
真做一个大一点的工程（几个人协同写一个几万代码行的程序或函数库），就知道有些东西存在的道理了。
说白了，一个人写程序，小打小闹，怎么写问题都不大，但是协同编程就不同了，这是工程。

koolcoy

原帖由 一介村夫 于 2009-10-28 11:19 发表

很多人都是站在实验室的角度看问题，没有上升到工程的高度。
真做一个大一点的工程（几个人协同写一个几万代码行的程序或函数库），就知道有些东西存在的道理了。
说白了，一个人写程序，小打小闹，怎么写问 ...

我面前就是公司的项目，源代码压缩后200M，解压后1G

koolcoy

无论是.c还是.h，static还是加前缀还是inline，都可以，前提是大家都必须按照一个严格的约定来，否则无论用什么都会出错。

include .c的坏处就是它跟C语言的习惯相悖。

wenggao

呵呵。好多大学教材就是如此啊。

shan_ghost

1、 对c/c++编译器来说，扩展名不对应任何功能
      这就好像 “匈牙利命名法” 不会给编译器增加任何功能一样。
      同样，绝不存在什么“因为用了匈牙利命名法，结果导致程序无法完成什么功能”的情况。

      这点我反复强调过，反复车轱辘回来很没意思。


2、既然扩展名不提供任何功能，那么遵循扩展名的一般约定就不会产生/抑制任何技术问题。
      唯一的差异，就是愿不愿意拿规范当回事。

      愿意遵守规范，那么无论是在 .h里实现、在 .inc 里实现（STL的典型做法）还是在 .share .code 里实现，都可以在尽量不违反基本规范的前提下解决问题——除了扩展名有所改变，不会有其他任何痛苦；但整个项目一下子就q清爽多了，其他人就不需要疑惑究竟哪些.c文件敢碰，哪些.c摸都别摸了。


3、正如前面一位朋友所说的： 命名空间是做什么的？ std:xx 和 std_xxx有本质区别吗？

如果真有合理的模块划分、并且还无法利用命名空间的话， 模块名_xxx 是否可以保证没有冲突？


4、事实上，如果真想解决问题，在.h+.c框架内完全可以做到。无非是对源码组织的要求更高了一点而已。

在 xx.h中include yy.h，相当于公开被引用的yy.h的接口；在xx.c中include yy.h，相当于隐藏 yy.h 提供的接口。
把某个内部模块先独立编译成静态库，然后再把这个内部静态库编译进供别人使用的模块（也编译成库），这样就可以避免内部模块的符号被暴露出去。
递归应用以上规则，有什么解决不了的？


5、wo level hen high, I dou can ba han yu pin sound xie de nobody neng look dong.

一介村夫

原帖由 koolcoy 于 2009-10-28 11:24 发表

我面前就是公司的项目，源代码压缩后200M，解压后1G

看见我标红的字了吗？

prolj

设计相当重要，代码量大并不能说明什么，我把一个十万行的模块消减到1W行了。
不知道村长的项目为什么include c，但是，我想表达，实际工程中要尽可能的简单，因为每一行代码都是自己日后的负担，该用的手段就用，比如goto，只要对项目开发维护有利。
设计不是为别的，是为了自己维护方便。

JohnBull

原帖由 一介村夫 于 2009-10-27 00:41 发表
我就经常include .c，对于不想暴露过多函数名的情况，把上万行的文件拆小便于维护。

拿无知当个性的典范...

持此观点者不妨到商店买一个痰盂回家盛饭——严格来说也没啥错误，管理水平高的家庭也不至于发生混淆...