linux 下 C 编程和make的方法 (五、准备写C代码)

中山野鬼 发布于 2012/03/30 21:59
阅读 1K+
收藏 13
    停下make的说明讲解。因为我讲得再多,就有点形而上学了。为了说明而说明。如果单就一个工程,一个src目录,上面的make说明,足以利用make完成代码编译等开发工作了,且不谈版本发布问题。同时,我还是希望交叉点,既然是linux 下的C编程和make。则也要说说C。选来选去,决定说说树。因此,先从tree说起。但在写C代码之前,我们得谈谈怎么样才算是个好代码,或者相对好点的代码,怎么规划代码。这些和tree没关系的闲话。
    有人说,快教几招实用的。虚的有啥好说的。我教你的劈柴,不告诉你得劈成什么样,你就会个动作,出去显摆,别人也不叫好,有什么用?写代码只是过程,并不是结果。无论自己用还是给别人评价,总要有个收获。因此,总得有个评判。由此我们先说说评判标准。啥是好,啥是坏。
    好的代码和好的系统一样,需要:
    1、稳定。
    2、安全。
    3、可塑。
    4、高效。

    这里一一解释。稳定,也就是可重复。电脑关了再开,开了再关,硬件软件逻辑是固定的,你至少得保证代码多次运行目标一致吧。这里不谈结果一致,是因为防止别人抬杠喷我,如就是要做个随机数输出,就是希望结果不一致。但目标是一致的。程序不是使用一次性筷子,只用一次。编程编程,编写流程,流程需要稳定,不然你编写它有什么意义呢。

    但有些入门而不熟练的人,会把程序的稳定和安全混在一起。例如

    int *p = 0;
    if (*q > 10){
    p = q;
}
    printf("%d\n",p);
有人说这是不安全的,也是不稳定的。我说这得怎么看。这里我把稳定和安全做如下划分:
    1、由于数据的改变,导致流程的输出目标不一致,这属于流程对灌入数据的不适应,这叫不稳定。也就是说,属于流程处理的数据变动导致的问题,属于稳定的范畴。
    2、由于使用者的行为改变,导致流程的输出目标不一致,这属于不安全。也就是说,流程处理的流动方向变化导致结果是否和目标一致,属于安全范畴。
    大家肯定认为我在嚼舌头。简单的说明,每个模块都是安全的,组合起来未必安全。每个模块都是稳定的,组合起来都是稳定的(只是效率有差异)。这算是最大的差异。也正是因为这样,在系统设计时不同的阶段,关注的目标不一样。你在模块组装,或模块相互协同工作时,独立测试要关注模块内部的自身安全和稳定,联合测试则只要对整体新规模系统的安全性进行检测。
    简单的举个例子吧。我家楼下的门禁。
    小区的每栋都有门禁系统。要刷卡,恩安全。而且每个登陆的卡,都能刷,同时根据权限决定,是否自动开门,恩,稳定。小区有地下车库,车库入口有刷卡匝,没卡一样进不去,又稳定又安全。但有个问题,为了方便,地下车库联通了每栋楼,换句话说,每栋楼的-1层都是地下车库,而且没有门禁,大家觉等整体是不安全,还是不稳定?
    稳定强调落入我的流程规范范围内的目标输出的一致。安全强调整体过程合理可控。回到上面的代码,因此怎么说,都是叫作不稳定,而不是不安全。这里说说病毒。大多数病毒利用的是系统不安全问题,例如无权限约束的系统文件改写,难道改文件有错吗?哪怕是系统文件,内核还可以替换呢。而也有些是利用系统的不稳定,例如代码本身的BUG。

    但从写代码而言,特别针对模块而言,安全问题往往是个系统性问题,可以少关注,稳定则是你编写流程的问题了。是必须要关注的了。诸如C代码中的指针等,都属于不稳定范畴。听到这,那位已经骑在窗台准备离开C学习,转学JAVA的朋友,先等等,这里比较高,跳下去 不安全,你跳,地心引力可以 稳定的让你向下,而不会让你向上飞。楼梯也是 稳定的,什么时候走,都能到一楼。不过这么高的楼确实不 安全,我们得把窗户安装铁栅栏,和富士康一样。
    安全在稳定中已经扯过了,谈下,可塑。这里要谈另外个词“鲁棒”,这个词我读研究生时,觉得简直是个万能贴或味精。但凡说点事情,都谈“这是个鲁棒”的系统。后来才理解,鲁棒综合了安全和稳定两个含义。讲究系统对内外部(内部就是过的数据,可以这简单的说)的变化,自身性质不会有所改变。但这个不是我谈的“可塑”。
    塑,即塑造,构造,也就是,可以重构的。或者拆下来再组装成另一种系统的 。如果还是原系统,那叫COPY。记得以前,比较早啦,上个世纪,刚学习面向对象时,有个书上说,面向对象有两个好处,一则,比较容易描述具备继承特性的对象群体的集合和关联。二则,可以令代码可最大化重复使用。于是乎,面向对象几乎成了万能的。什么东西都琢磨琢磨上面向对象。典型的例子就是用C++实现数据结构。有些数据结构用面向对象比较好。典型的是字符串。但有些数据结构,例如堆栈,你用面向对象实现,有这个必要吗?这和拿JAVA讨论算法计算性能一样无聊,你用JAVA就是快速实现面向对象的开发任务,在虚拟机上你谈什么计算性能啊?甚至有人把C,C++,JAVA同样写点算法,跑跑,居然得出JAVA其实不慢的结论。大可不要信,权当风景看看就行。
    其实C也可以做到高度可塑的,不是面向对象,而是面向模块。力求模块的最大化利用。典型的,利用最广泛的,就是库函数。说到可塑,必然谈到两个问题。
    1、模块的合理划分。
    2、模块内部的稳定性。
    前者包含了模块与模块拼接的效率问题。后者是个写代码的问题。这两个问题都没办法具体化。唯一说说的是,我们怎么组织C文件。前面说过,C标准每个编译针对一个文件。因此,如果把一个独立模块分在几个文件里去实现,不靠谱。把多个模块写在一个文件里也不靠谱。最好的标准,就是一个独立模块就是一个文件。但此时又出现两个问题。

一个是哲学问题,在物理中也存在:什么是最小的?

一个是系统问题,如何让一个C文件尽可能的不依赖其他文件。

    两个都挺难的。比如,第一个问题。有人说,一个函数的代码正常情况下不要超过50行,恩确实,但极端的人说不要超过25行也没错。还好我们的计算机体系结构对于高级语言,再怎么细分也是不会到机器指令的细分,但到快接近机器指令的程度已经没有高级语言存在的必要了。你干脆写汇编得了。
    而第二个问题,很少有不调用其他C文件的代码,你但凡调用就有关联。一关联,就不能解决一个理想目标,让C文件不依赖其他C文件。
    先解决第一个问题吧。我的态度是,有个逻辑组合,具备存在价值,而该价值的存在是不可拆分的。那么这个逻辑至少可以独立成一个最小单元。在C语言里,就是函数。别把函数想的太复杂或比较独立。函数就是描述一个不可拆分的,用语句组合出来,具备独立存在价值的逻辑集合而已。哈,我这等于在转移矛盾,把问题替换成,什么是独立存在价值。这个得具体问题具体分析了,包括可重复利用的角度。
    第二个,理想目标是否存在。哈,确实不存在。可以反证明嘛。
    假设每个模块均独立。那么模块与模块的关联的实现归属于哪个模块?如果归属于已有模块则和假设矛盾,反之则存在新模块和假设还是矛盾。 这个证明,希望大家不要认为多重要。
    但证明的陈述值得看看。也就是说,系统存在两类模块,一类是独立的,一类是模块与模块的关联。由于关联本身是系统自身确定的,除非系统自身作为一个大模块,否则,对于可复用是胡扯蛋的事情。因此,着重非关联的代码设计很重要。
    可重用,模块划分,还需要扩展,这里先打住,我们先看下效率。就是程序的高效性。
    高效性,一定是最后谈的,因为,不安全,不稳定,不可塑的代码,高效死了没有用。有人说,不对,我们在性能优化时,为了提升速度,就是尽可能的不要模块来模块去,恨不得几个函数合并起来,改成汇编,甚至用到特殊指令集。就我谈高效,以前给别人说,从效率上来看,按照以下,性能提升能力是逐渐减弱的。   
    1、理论优化
    2、系统优化
    3、逻辑优化
    4、指令优化
    举个例子。比如排序。快速排序和冒泡排序,对于N大于一定数后,性能差异很大,这就是理论的优化。你汇编死了,理论上的计算步骤少不了,你有多大能耐?
    还说排序。系统涉及到硬件,操作系统等等。整个硬件都你控制,但是你的数据量大于CACHE,或内存,你还是会慢。指令有啥用?但有人反驳了。按你的逻辑,系统优化,那么不同系统怎么复用,怎么兼容,难道不同的硬件平台重新写一套?话不是这么说。硬件平台确实有差异,但是计算机组成原理比较相同。也没说硬件平台一定要重写代码啊。C语言强大的#define ,#if 等就可以搞定一些硬件特性的调整。而且很多实际逻辑组合和硬件关联度不大。

    还说排序,实际操作步骤总要落到实处,比如快速排序,是用递归,还是不用递归,这不是理论问题。不是系统问题。也不是指令可以解决的。递归你就玩去吧。且不谈不同的实现方法有的可并发有的不可并发,不可并发的,你有并发指令集有什么意义?

    曾经有个例子,一屁乘加完后,有个加法再右移,用汇编,就一个移位器,只能做2组16位的移位,而且和乘法器结果必须空等2个cyle。但是有4个乘法器,咱不右移了,继续左乘,让最后有效8位落到高8位,而且有pack指令,直接组装,计算数量由大,还不用空等。这是逻辑优化,有人说你胡扯淡,不就是利用了DSP的并发指令嘛?那么如果卷积过程大于可容纳的位宽呢?这个限制直接导致实现方法的改变,怎么能说是指令优化。

    最后才是指令。虽然一般情况下,指令,特别是特殊汇编指令集,比如类似DSP,我的经验可以并发的,通常手写比最大自动优化编译器的效果好4到 20倍(那也是加上了逻辑优化的综合效果),要么我也不会被别人说是“人肉编译器”,不是我强,是C语言描述一些特殊指令集的组合使用很麻烦,但基数都是被前面的优化所确定的。到这步,基本上没优化前,就能看到你系统的性能了。所以说,高效,即便不谈程序是否有意义(跑都不稳定,跑都不安全,代码不可改),也得放最后谈。
    总结一下,C程序设计,讲究,稳定,安全,可塑,高效。否则没意思了。
    这里补充一下,可塑,模块化设计思想。系统设计,经常有两个相反的名词,从顶到下,从下到上。就是我们先规划整体,慢慢裂变,还是先分割模块独立实现再进行组装。其实都可以,只是操作要注意。而且两种操作都存在独立模块,和关联模块的区分。对于后者书本上基本很少说。画图太累,纯理论文字估计大家会睡着,不如举例子吧。说下家庭房屋功能分割。没有房子,没装过新房,你总住过父母的房子吧,再对比大学宿舍,没上大学的全当我没和你在说事。所以大家多少有直观的感觉。
    请大家举手,谁家你睡觉的床边上就是马桶。你宝宝的尿盆不算,固定的。再请大家举手,谁的学校宿舍,假如某个宿舍房间没马桶,而某个宿舍房间有马桶,前者的同学按照学校管理规定,有资格天天去后者的房间便便的?
    没错,马桶就是马桶,是个功能模块。一定要独立出来,没条件每个宿舍放个便便间,但至少一个走廊有个独立的房间是便便间。同时,便便就是个独立模块。但上面的情况不代表我们每个独立模块都要个关联模块。这又怎么说呢?宿舍没马桶,难道你打开宿舍门,就可以便便吗?显然不能。但好点房子,卧室里面有自己的卫生间。你不用出卧室,打开卫生间的门,就可以便便,当然此处省略走几步,转身,脱裤子等贾平凹的细节描述。
    那么上面两个不同的情况,房间里面有马桶,走廊尽头有马桶,关键节点在哪?是马桶的圈圈,还是卫生间的门?显然是卫生间的门。有人反对了。集体宿舍,那卫生间叫一个大啊,多少个坑坑啊。应该每个坑的坑门是关联点。这里有个问题啊,难道卫生间有这种区分,这个坑专门给女性用,就是到男生宿舍拜访的女生,其他只给男生用?如果有,我承认,卫生间的大门不是关联点,你就是去掉大门,还有要选择的。如果每个坑坑都一样,或同一类,只不过有坐式的,蹲式的,还有站式(谁用谁知道,此处不解释),那都是便便用的,管它是大还是小。
    这和写代码有什么关系啊。有关系。我们按照从顶向下的设计方法来看,实际是我们知道一个楼面,开始规划,反之我们是已经有了各个功能房间开始组装。务实的谈到C编程上,则我们如何组织C文件。
    有两种做法,一种,在一个设计图里,设计出各种马桶,在另一个设计图里,设计好所有的卫生间。但是需要引用马桶设计图里的设计。还有种做法,一个设计图是专门给居家用的,里面包含了马桶,卫生间的内容。另一个设计图是给穷学校,不能让每个宿舍房间都有卫生间的客户使用的。设计图就是C文件。我们用哪种?其实不用问我。你们去问问专门做建筑规划的。他们的设计图通常怎么布置的。如果他们的方法没有可取之处,他们这么多年吃白饭的?
    通常,马桶是这样设计的:和卫生间放一起。但有个特例。啥?库函数。为什么库函数通常如五金店。一对东西放进去,随便让你挑。想想也明白啊,标准的库函数作为OS和软件的接口工具,谁知道你想做什么,因此分门别类。但通常这不是你做的事情。回到目标上来,如何组织C文件。大多数情况应该按照如下原则:
    1、文件文件之间层次化。
    2、文件内部模块完整化。
    关于第一点:很简单,一个C文件A,如果调用了 B文件的函数。而B文件调用了D文件的函数,那么,尽可能的不要A调用D文件。原则上绝对禁止这么操作。文件与文件的依赖性,使用make处理。
    关于第二点:如果一个内容,不属于你调用的C文件所能提供的,又不属于你需要提供给调用你的C文件的,原则上,不要在其他C文件里实现。无论内容多少。如果超过3000行,可以考虑分层,将文件依赖关系隔离,就是B调用了E,E调用了D,B,E文件包含了原先B文件的所有任务实现,但新的B不调用D。

    综合一下上面两方面的内容。什么是好程序,和如何规划文件。给出点额外的东西。
    1、只要不是对调用你的C文件有直接关系的,一律用static静态确定起来,同时所有static的,在你设计程序时,落入稳定性关注,同时不要存在稳定性检测逻辑。例如,判断指针是否0.为什么呢?因为这个函数要想被调用,一定是由外部进来的,你当你移动啊,进了公厕大门收费,进了蹲坑门还要收费?
    2、上述的反之,C文件对调用者(外面给进来的)一律需要稳定性检测逻辑,但对被调用的,或者自身使用的,不要增加稳定性检测逻辑,例如一个指针,B文件的函数传递给C文件,C文件传递给了D,则,B传递给C时,C的入口函数要检测,但和B一样,在调用D文件的函数前,不要检测。这是提高效率的做法。也是反过来保障可塑的做法。因为你能决定你调用谁,你不能决定谁调用你。但有个情况需要注意,回调函数这已经不是一般的概念了,得另说。
    3、安全性检测。两种做法。组合枚举法,总线约束法。前者就是A有5种调用,B有4种实现,你组合20种不同逻辑一一测试检测。后者,A,B都只受总线约束,只要9种。但是是不是后者一定好呢?显然不是。画蛇添足,比如组合后就2种方式,还不是重点。重点是,但凡总线约束法,会增加你系统规划的逻辑,总线本身是在系统原始设计任务中不存在的。只是为了资源的集中管理和利用,才有总线的概念和设计任务的存在。你就是要睡觉和便便,为什么需要家里添个走廊。便便要经过它,睡觉要经过它,洗澡要经过它,烧饭还要经过它。

    4、模块利用。如果多个文件共同完成一个任务,想作为独立模块被其他系统使用,组装嘛,那么用一个文件不妥啊,不能解决所有问题,因为有递归效应。模块可能是模块的组合呢,究竟那个层级的模块放一个文件中?,因此但凡是多文件组成的模块,则此时用目录。目录好啊,树状结构,我摘个子目录COPY到另一个工程里,只要这个目录的文件不引用其他目录的东西(标准库不谈),就可以不用担心依赖问题了。而该目录下,有独立的make文件,子目录的内部依赖都解决了。还不够你爽的?(其实这里已经在挖坑了,如何在 make 下让多个目录的 makefile自动化工作,这个坑现在,以后咱们再跳一跳)。

    这里要引申说一下,调用别的库的问题。假设的系统如下分,最高层a,下面有个模块b,模块b又是模块c,d组合的。a调了一个库,b调了一个库,c调了一个库。通常弱手就是一对库放在一个lib里,然后gcc 后 一堆 -l 。庆幸你熟练使用make,不怕。但是模块移动再利用时,你就改把,改啥?新的make啊。因此,每个目录都有个lib自己的目录下的src内的代码调用的库放在自己目录下lib里的库。利用库时,我没说只把src ,inc ,和 makfile等文件COPY啊。直接打包复制过去。这里有人又提反对意见了。我a里调用库和c里调用库的版本不一样,我怎么检查。关我屁事,只要你两个库不是又交叉同时引用到一个独立的库,否则,c层目录下的库就是老版本,至少保证c模块的正确性,你a里调用的库是你a独立代码的事情。我c不是直接给你a用的。是我做好库文件再被你使用的。有问题吗 ?(当然注意是不交叉同时引用另一个库包括相同函数),当然为了和谐,尽可能的要保证不同层次的引用相同库的一致性。同时,除了标准库,不要跨层使用。不然你已经违反了模块化的原则。a,c两个层都用到一个库,而这里的库是一个专门的模块,你为什么不让c全部完成掉呢?你可能说我要快,我不想函数掉函数,靠!!要快,你需要c做什么。有本事你重写去,记得一个常识,80%的时间只运行20%的代码,利用这个尝试重新规划你的系统。别拿不合理规划的系统来反驳合理的模块划分方法。

    总结一下,既然咱们玩C,那么就要有模块化的思想,同时你先别急着学招式,例如while  和for是循环这种玩意,先得琢磨什么是好,什么是不好,这就是我这个章节的目的。心急吃不了热豆腐,难道你看到“若练神功,必先自宫”就去轮菜刀吗?不及不及“即便自宫,未必成功,纵未自宫,亦可成功”所以,安心理解一下这个章节,对后面C代码的实际展开是有帮助的。程序编译通过,不代表是程序,只是代码的组合符合标准规范而已。程序可运行,也不是目标,只是它在某个特定情况下,姑且可行而已。
加载中
0
中山野鬼
中山野鬼

引用来自“Java行者”的答案

不错,@中山野鬼 继续
前两天抓个不是BUG的BUG,耽误写心得了。呵呵。
0
___py_liang
___py_liang
好文! 我工作也是c 对模块简的耦合比较头疼!c需要严谨的代码作风。
0
风林火山
风林火山

@中山野鬼   @红薯           两位我发现如果我想看野鬼这个make系列要找n多页,才能从他的最后一篇找到他的第一篇,是否需要一个功能他,来连接他的所有系列。(另外,野鬼确实没按常理出牌,将内容都写在讨论区了。但是即使是博客也比较乱,出来的内容不是按博客标题索引,而是他的回复。。。感觉很乱啊。)

0
风林火山
风林火山

引用来自“风林火山”的答案

@中山野鬼   @红薯           两位我发现如果我想看野鬼这个make系列要找n多页,才能从他的最后一篇找到他的第一篇,是否需要一个功能他,来连接他的所有系列。(另外,野鬼确实没按常理出牌,将内容都写在讨论区了。但是即使是博客也比较乱,出来的内容不是按博客标题索引,而是他的回复。。。感觉很乱啊。)

@红薯
0
defu
defu
说的有点抽象啊,要是有实例应该更好理解点,感谢分享,继续顶。。。
0
换大米

我觉得的程序的安全性和稳定性是两个交互范畴上的东西,稳定性应该是代码自身的问题,从代码到代码,实现目标就是相同的输入总可以获得相同的输出,这个输出不是显示出的具体结果,而是程序设计实现的预期。

而安全性更多体现在交互这个问题上,比如说内存泄露这这样的问题,我们不能说代码不稳定,比方内存无限大这个前提下,那么即使泄露了,那么着个程序依然能输出我们期待的目标结果,但是他却掉这个前提,内存泄露会影响操作系统,会影响其他程序,最后导致自身的崩溃,那么就形成所谓的不安全了。

还有如楼主所说想系统安全漏洞问题,比如中了木马,但是系统仍然正常使用,那么我们说他是稳定的,因为我们做的任何输入,系统都会给我一个预期的输出结果,但系统却是不安全,因为他们可能木马可能窃取了我们的信息。

所以安全更多是指程序与外部交互,而稳定却是只自身运行使得输入是否总能符合预期

浅见

0
换大米
还有楼主对函数的描述,应该是就是所谓的原子函数的问题吧?
0
米兰的小铁匠
太抽象了,还没到那个水平。
返回顶部
顶部