《C语言编程之 Unix C编程问题精粹》由会员分享，可在线阅读，更多相关《C语言编程之 Unix C编程问题精粹（8页珍藏版）》请在金锄头文库上搜索。
1、Unix(Linux) C 编程问题精粹编程问题精粹文章目录 第一章:前言 第二章:约定 第三章:开始任务 第四章:使用 lint 第五章:使用 make 第六章:优质无错编程 第七章:调试技术 第八章:其它更好的文档 第一章:前言 对于 c 语言,有人认为它已经落伍了.对于这个问题,仁者见仕,智者见智.的确,c+比 c 有更强 大的诸多优势.但 c+是建立在 c 之上的.这也是 herbert schildt 所著的在全世界畅销不衰 的原因.更何况,要深入学习 linux 就必需要有相当的 c 功底.(这也是我搜集整理本文的根由:-) 现结合个人在编程中的体会,为使新手少走弯路,为老手锦上添
2、花,因此无论你是使用 c 或 c+编程,也无论你是程序设计的初学者还是成熟的专业人员,均会发现,本文将会对你有所收 益.当然,我尽力写得清晰易懂,又不古板. 我爱 c.(正如世人爱上帝一样:-). 你可以在 上获得此帖的文本.而其 html 版本正在赶制之中. 如果你是在一个月之后看到本文,那么此文或许已经更新了:-) 第二章:约定 专业的源程书写风格. 先看看世界级 c 大师的源程书写风格.如 steve maguire 就有许多不错的建议. 倡导使用易于理解的“匈牙利式“的命名约定. 所有的字符变量均以 ch 开始; 如: char ch_*; 所有的字节变量均冠以 b; 如: byte
3、 b_*; 所有的长字变量均冠以 l; 如: long l_*; 所有的指针变量均冠以 p; 如: char *p_ch_*; 建议类型派生出的基本名字之后加上一个以大写字母开头的“标签“.如: 分析 char *ppchmydata; 其让人一眼就能看出它代表一个指向字符指针 mydata 的指针. “匈牙利式“命名的最大不足是难念:-( .但相对于不是总统演讲稿的 c 源程来说,这又算得了 什么?想想看以下的数据命名: char a,b,c; long d,e,f; . . . (反正我是不会再看下去了.) 倡导规范书写. 如果你思如泉涌,而不去也不及顾虑书写格式,那也没关系.在将其交出去
4、之前,用 cb 命令格 式化你的源程.虽然源程的格式不会影响到你编译结果的正确性,但切记,能让其他的程序员 能轻松地阅读它.否则没人会理你的. 关于 cb 命令的更多用法,可以用 man cb 来参考其手册页. 当然除了 cb 之外,还有更多更好的.但 cb 是你在任何 unix(linux)上都找得到的.更何况它并 不差. 第三章:开始任务 开始任务之前,先做个深呼吸! 其他文档你准备好了吗? 你是不是除了 c 源程之外一无所有了吗?兵马未动,粮草先行.你必须先清楚该程序所要完成 的功能.在开始写程序之前,对程序的功能应有规范说明.书写规范书和确知程序功能的一个 方法是先编写相应的操作手册.
5、如果你是一人单干,劝你首先写需求书.切记切记,这对你意味 着事半功倍的大好事. 一个实例:我计划为本行的信贷子功能模块打一个补丁.我用 10 周的时间用来写规划书,需 求书,操作流程,使用说明等等文档.之后用 2 周的时间编写程序,在初步测试(1 周)后递交给各 信贷部门测试使用.然后根据反馈的信息再更改相应文档,并根据文档修改源程.6 个月后发布 正式版. 一定该遵循 ansi 标准吗? 如果你仅使用 ansi 的标准首标文件,恭喜你,你的程序有着全世界范围内的广泛支持和兼容. 光明无限.但你必须在通用与专用之间做出取舍,对不起,我帮不了你. 我的原则是:核心用 ansi,界面按需而取.这样
6、在转换平台时仅需另编用户界面而已.实用至上 嘛. 附:ansi 标准 c 头文件 是不是很寒酸? 再续前缘? 在得到新任务之后并在开始该新任务之前应马上回想有哪些是曾经拥有的.旧调重弹远比 另起炉灶来的高效与环保. 是否该有自已的库? 我的答案是应该有自已的特色库,并与 ansi 兼容.与 3.8 不同的是,你仅需在源程序之后附上 自已的专用库就可以了.其次在有了自已的库后,源码会很精炼的.不用去羡慕别人了吧. 要学会条件编译.注意你的平台特性.(高手的标志?) 除非你确定你要写的程序是在某特定的 os 特定的硬件平台而量身定做.否则应注意数据类 型的长度,精度都是不同的,不要想当然.有时甚至
7、是不同的编译器的差异都要考虑考虑. . .(欢迎您来充实此处空白) . 好了,在任务中,又有哪些细节呢? 我是不是葛郎台? 不要那么吝啬.在源程序中加入详尽的注释以使自己和他人即使在许多年以后仍能读明白 它是什么样的程序. 用注释行分离各个函数. 删除不需要的代码时要小心. 一个好建议是:使用#ifdef del,而不是简单地注释掉甚至是粗暴地直接 dd.如果你是使用/* . */,但一旦要删除的代码有很多行,或注释中以有注释时,这就可能不那么好使了. 如何给源程序文件命名? 表现特色且不与任何原有应用名相同.一个简单地方法就是试试看,系统有什么样地反应? 一次只修改一个地方. 一次只编写一个
8、单一功能的函数。 编写通用程序. 只有当程序编写完,并且完成了所需要的性能要求之后,再反过头来优化该程序. 不要使用 a.out 作为结果.你大可以使用与源程相同的可执行文件名. 是否一定要用 vi 编辑? linux 下有许多专用编程编辑器.它们能使你有更高的效率和更低的低级输入错误,但我还是 要劝你至少要熟练掌握 vi.毕竟 vi 遍地开花. 协同作业.请相信,你不是在孤军作战.因此,你有必要熟练掌握一些其它的工具.如 . .(欢迎您来充实此处空白) . 第四章:使用 lint lint 没有你想象中的那样糟糕.相反,一旦源程序形成了没有 lint 错误的形式,将很容易保持 下去,并享受到
9、如此而带来的好处. 在 cc(gcc)之前就应使用 lint. lint 是一语法检查程序,对于这个多嘴的婆婆来说,你应有足够的耐心.虽然你知道自已在干什 么,但在 cc 之前使用 lint 总是一个好习惯. lint 有哪些特色? 在编译之前使用 lint 的重要原因是 lint 不但能发现 ansi c 中的语法错误,而且也能指出潜在 的问题或是难于移植于另一机器的代码问题.除了能指出简单语法错误之外,linut 还能基于 以下原因指出另外的错误: a.无法达到的语句. b.没有进入循环. c.没有被使用的变量. d.函数参数从未使用. e.没有赋值之前自动使用参数. f.函数在有些地方有
10、返回值,但在其他地方不返回. g.函数调用在不同地方使得参数个数不同. h.错误使用结构指针. i.模糊使用操作符优先级. 呵呵呵,挺有用的吧! 如何控制 lint 的输出? 有时 lint 会有一大屏一大屏的警告信息.但似乎并未指出错误.为了找出潜在的错误则需费心 费力地浏览这些大量的警告信息. 但如果你的程序会分出几个独立的模块,在初级启动 lint 时不要用可选项.当对这些模块进行 更改或扩充时,可以忽略与代码无关的某些警告.为此可用以下选择项: -h 对判别是否有错,类型是否正确不给出启发式测试. -v 不管函数中没有定义的参数 -u 不管被使用的变量和函数没有定义或定义了但没有使用.
11、 干脆,在程序中插入指令来影响 lint 运行.它看样子有些像注释. /*notreached*/ 不可达到的代码不给信息说明. /*varargsn*/ 函数的变量个数不作通常的检查,只检查开始 n 个参数的数据类型. /*nostruct*/ 对下一个表达式不作严格类型检查. /*argused*/ 下一函数中,不给出没被使用参数的警告信息. /*lintlibrary*/ 置于文件的开头,它将不给出没被使用函数的警告信息. 关于 lint 的更多用法,请用 man lint 来获知. 第五章:使用 make 什么是 make? unix(linux)是一个天生的开发平台,我为此感到高兴.
12、make 是一个强力的工具.它能自动跟踪 相互依赖的源代码块并组成一程序,使得很容易建立一可执行程序.make 就是这种有依赖关 系的部分和代码之间所作的规格说明. 所有的程序都要使用 make? 是的.尽管你只有几个简单的模块,但你需要有一种结构来支持它从简单走向复杂.除非你的 程序已经盖棺定论. makefile 由哪些组成? makefile 由以下几个部分组成: 注释. 使用#符号插入.make 将忽略#之后的任何内容以及其后的 return 键. 变量. make 允许定义与 shell 变量类似的有名变量.比如,你定义了 sources=prog.c,那么该变量的值 $(scour
13、es)就包含了源文件名. 依赖关系. 左边是目标模块，后接一冒号.再接与该模块有依赖关系的模块. 命令. 以 tab 键开始(即使用相同数量的空格也不能代替它). makefile 示例 下面介绍一个简单的示例来说明 make 的用法.假设你的程序有两个源文件 main.c 和 myc.c, 一个位於子目录 include 下的头文件 myhead.h,一个库由三个源文件myrout1.c,myrout2.c,myrout3.c 产生. 其 makefile 文件为: #一个基本的 makefile 文件. #其中包括个人的头文件和个人库. headers=include/myhead.h s
14、ources=main.c myc.c product=$(home)/bin/tool lib=myrout.a libsoures=myrout1.c myrout2.c myrout3.c cc=cc cflags=-g all:$(product) $(product):$(sources) $(cc)$(cflags) -o $(product)$(sources) lint:$(product) lint $(sources)$(libsources) 哈哈,挺象 shell 编程的.如果你与我一样使用 linux 下的 gcc,那么只要把上面的 cc=cc 改为 cc=gcc 即
15、可.怎么样,想来一个更复杂点的吗? 一个更为复杂的 makefile 你是否注意到,在上例中,只要启动 make,就会重新编译所有源代码. 如果你能看懂以下的 makefile,恭喜恭喜,你通关了. #一个更为复杂的 makefile headers=include/myhead.h soures=main.c myc.c objects=main.c myc.c product=$(home)/bin/tool lib=myrout.a libsources=myrout1.c myrout2.c myrout3.c libobjects=$(lib)(myrout1.o)$(lib)(myrout2.o)$(lib)(myrout3.o) include=include cc=cc cflags=-g -xc lint=lint lintflags=-xc all:$(product) $(product):$(objects)$(lib) $(cc)(cflags)-o$(product)$(objects)$(lib) .c.o: $(headers) $(cc)$(cflags) -c i$(include)$ $(lib):$(headers)$(libsources) $(cc) $(cflags) -c $(?:.o=.c) ar rv $(
