今天我在回答一个问题的时候,提到了 PJP的这本 C标准库。
这里我首先简单说一下
这本书,我的确是全部看过一次,而且对于其中的一半以上的章节,我都认真看的,乃至它的函数接口声明,我还全部特意手抄了一次。
当然,对于 limits这种看起来简单,实则很容易疏忽的东西,由于它的内容实质上是几个 宏,所以我没有抄,而当时的理解也有限,后来也没有再去看。
由于我在回答里夸下海口
我敢说真正意义上的 介绍C标准库 的仅此一本,所以我有点怂,谷歌了一下,不过看起来,我当年的记忆不假,的确独此一本再无第二。
不过与此同时,我也看到了网上把这本书吹的神乎其神。
这里我要说几点,这也是基于我自己看这本书的 实际体会
我说过,这本书,由于它的作者,P.J.Plauger,他本人开了一家软件公司,主要就是卖高质量的C/C++库,而他自己也在C语言标准化的X11工作组内担任重要委员。
应该说,在如何实现和定义C标准库方面,此人为当世少有的几个专家——所以我猜想,在他之后,也许很多年里不会有人敢写C标准库。
就内容而言,此书确实极其有价值,因为它讨论了很多标准库的设计和实现的考量,方法,和历史沿革。
但我必须再三强调,我们的很多人,实际上根本不会去设计C标准库。
——腾讯阿里也许需要招人去优化实现 TCP IP协议栈的实现,那是因为他们有明确的商业利益。
但C标准库呢?说实话,以我愚见,没事不会有人试着去重新实现和优化C标准库。
因为C标准库对于大多数普通应用,最常用的功能往往只有不到5到8个库,(对于我自己的体会而言,最最最最最常用的只有三个 string.h stdio.h stdlib.h )。
而我还经常看到有人自己实现 memcpy printf这种基础函数。
这些人可能连assert都不好好用——正如我们开发代码,从来就没正儿八经开过 Debug和Release编译选项——真不知道是我无知还是大家都很少使用。
其实恰恰是符合20/80定律的。
总之,我的意思是,这本书本身的确值得被推崇和尊崇,多夸张都不为过(就公开出版图书范围内,再无一本能与之相比的角度而言)
但是,我们一定要清楚明白,这本书对我们的实用价值,实际上是不高的,或者说,非常有限。
——当然我并没有因此就跟你说,这书你没必要看了。
因为至少对我来说,看这本书的过程里,尽管我是抱着八卦自己用了十几年的一门语言的周边,但在这个过程里,我确实被潜移默化,明白了一个优秀的C模块,优秀的C程序库应该怎么写。
说个羞羞的事情,其实前些年,我一直以为自己在 C语法方面,达到了相当的造诣。
这么说也不是完全瞎吹牛比,确实那时候,大概是我刚刚写完我自己人生头五万行C代码的时候。当时的状态确实有点像高三高考的学生,随便抓一个出来都是上知五百年下知五百年,天文地理无所不通的人才。
不过,在后来的时间里,我在工作上并没有什么更大的进展。
显然,单纯精通C语法本身并不会对实际业务能力有什么很大的帮助。
你能明确理解左值右值,乃至优先级,甚至加上变态的结合性,可以说,在这方面你已经算是相当了得的人物,至少出去和别人争吵,大概是不会被欺负的。
但是,那有什么用呢?
我轻轻使用小括号,轻轻把长表达式拆成几行写,屁事没有。
省事而直接,还不容易出毛病。
在实际工作中,即使就编代码而言,最重要的能力应该是两点:
1.准确理解实际要做的到底是什么,然后是用简单快速的方法实现它。
2.出问题调试的时候,有清醒的头脑,不要深陷其中不可自拔,这种人通常面临两种危险
其一,陷入自己正在追查的逻辑链里出不来,最后经常为了验证确保逻辑链上的一个怀疑而忘记了自己本来在干什么。
其二,陷入在对问题的猜测和定位上。
我们经常有这种体会,我们发现并且改了很多其他BUG,但是我们没有改掉测试反馈的那个BUG 。
在这方面,有时候如果是一个喜欢看侦探小说的程序员,也许会好一些。
说实话,我本人这方面可以说极度低能,也恰巧我一点都不喜欢看侦探小说。
不过我还是有必要介绍你去看一本经典著作 软件测试的艺术。
此书成书年龄大于大多数你我中人,此书首版于1970s,我本人生于1987年。
如前面所说,早年,我很为钻研C语法自得,现在如果翻出当年我写那些帖子,连我都会怀疑自己是不是吃饱撑着。
那时候我还特别喜欢和别人争论打赌,不过也不知道是真的有几把刷子还是怎么回事,在大多数时间里我总是处于上风。
最后代码输出的结果总是如我所料。
尽管没什么实际作用。
与此同时,我也很关注所谓的程序架构,即使我做的只是简单的单片机程序,可以说,我在这个问题上至少纠结了五年。
期间我变换了很多种不同思路,基本上把后来我能看到的所有别人用过的方法都用了一次——这其中有我自己偶然的心得,当然更多的其实是我看了大量这方面的书后,受启发做的。
比如当年我在如何封装底层,提供基础的操作原语这件事情上,纠结了许多年。
不客气的说,实际上,Arduino这种思路我自己独立思考过——当然了,认识我的人都知道,我实际上很鄙视这种思路。
但最后,我认识到,单片机而已,写个BSP就得了,非要搞这么深奥吗?
还HAL层,还硬件层,说实话,我现在一点都不爱HAL层,我总是喜欢一步到位,以函数提供接口。
到了换了一个板子一个项目,我直接重写一个新的BSP。
而且我再也不想要分那么多层。
我的程序里只有两层,一层,BSP,第二层,应用。
这才是小巧的单片机程序应有的风格——当然这是我的看法。
困得快死了,随便扯几句睡觉了,反正我没啥负担。
说到吵架这事,其实在之湖上我从来没有因为技术问题和别人吵过架。
倒是一些生活的八卦情感专场破烂玩意,有时会引发我和别人吵架。
我突然回想了一下,似乎从三年前开始,我就不再喜欢和别人纠缠语法细节了。
我甚至有意回避那些我曾经引以为豪的手法。
这不仅因为我认为这是一件很没有意义的事情。更因为我觉得,这其实是一种肚量。
以前我总是吐槽 咱这乎总是在贩售焦虑。
但其实仔细想想,外界不管如何,如果我们的心是干爽的,那再潮湿的世界里,我们也是干爽的。
所以我放弃了对哪些会让我怒发冲冠的问题提出投诉——当然也大多数被忽略了。
这个世界乱糟糟,就像知乎一样。
我呢,只看我想看的八卦或者问题。
我知道其中很多陷阱很多骗子,一如外面这个世界,但是,我以自己的眼力,自己的耐力和气度,好好在其中穿行而过。
至少,我不会再和这些无关紧要的 或者骗子过不去。
本文围绕C标准库相关书籍展开,提到P.J.Plauger所著的C标准库书籍虽有价值,但对多数人实用价值有限。同时指出单纯精通C语法对实际业务帮助不大,强调编程中准确理解需求、调试能力的重要性,还分享了单片机程序架构的看法。

被折叠的 条评论
为什么被折叠?



