C++学习难度深度解析

发表时间: 2019-11-11 15:45

知乎上看见的文章

C++之难不在于其语法的复杂性,也不在于二进制层面上语义的杂乱无章,更不在于玄妙得不食人间烟火的模板推导(模板元编程),这些都只是表象。本质上讲,C++跟任何语言比,它很独特很怪异(废话,任何一种语言那个不特异)。

很多时候,C++给人的感觉就是,好像任何一种语言的特性(这话有点夸张),都可以在C++王国中,通过令人发指的奇技淫巧,罄竹难书的花样作死,最后终于可以在一定程度上模拟出来,但是模拟后的结果,又总是存在这样那样的不足,要么因为内存管理,要么因为反射的原因,总之,就是好像可以做一切事情,但最后终于做得不好。这个时候,猿猴要么就直接扑上原生带有这种特性的语言,要么干脆就完全舍弃,放弃治疗,啥技巧也不用,返璞归真,就老老实实一行代码一行代码、不厌其烦、不畏枯燥地一再写地重复类似的功能。而C++自身的优秀特性(析构函数、内存管理、模板、多继承等等),没有任何一种语言整的出来,当然,也可以说,这些玩意都是为了解决C++自身制造出来麻烦,other语言s完全不care这些杂碎。难道,这些好东西就没有一丁点价值了。

更令人难堪的是,迄今为止,C++业界就没有出现过方方面面都让人满意的基础库,也即是性能(对c++猿来说,性能最重要)、可扩展性、易用性、安全性都经得起推敲。所有的通用库、流行库都存在这样那样的诟病,stl如是,boost如是,qt如是,……。所以,就开始有人(现在是普遍都持这种观点啦,十几年前还只是开始)怀疑了,为什么其他语言出来不久,就马上配套相应的官方基础权威平台框架库,就算是C语言,也有标准头文件库,里面也确实没有可争议之处。就C++诸多借口,迟迟交不出答卷。这一定是语言的问题,毫无疑问。就算不是语言的问题,你看看,几十年下来,多少大牛,就搞不出来的东西,由此可见,C++有多麻烦,有多复杂,平常人hold得住吗?

可是,基于C语言,C++多出来任何特性,都确确实实很有价值,用得好,的而且确,可以节省很多很多重复代码。就算最让人诟病的隐式类型转换,虽然一不小心,就给猿猴惊喜,带来理解上麻烦。但是,在可控的情况下,真的可以少写烦心的代码,某些场合,也是奇技淫巧的用武之地。好吧,既然low C都能写出来基础通用库,反而高大上的C++就举步维艰了。问题是,精致的C代码,到了C++舞台上,马上就备受一连串很有道理的指责,类型不安全啦,缺乏弹性啦,不够易用性,甚至连性能(明明在C那里就是极限了),也可以榨出汁来。既然你大C++这么厉害,你行你上啊,少在这里瞎逼逼。几十年了,你换了多少次新马甲,依然虚有其表,金玉其外。可以想象大C++的老脸有多红啊。

所以说,这个世界的猿猴语言分为两大类,C++与其他语言。其他语言稍微努力就能做出来很有群众基础的通用库(不接受也不行,压根就不让你做文章,就不给你后门更好地实现),进而跑步进入共产主义,人生苦短。而C++看着其他语言的通用库,就会瞎逼逼,指指点点,这里不好,那里不对,但是自己无论如何,就是只能做出来小团体运用,自我陶醉的通用库,这些所谓的通用库,最后多半要被历史潮流所淘汰。

当你废了九牛二虎之力搞清楚了C++的对象模型(继承、多继承、虚继承、异常、……),各种数据类型在内存中表示,还搞清楚不同编译器的不同处理方式;兴致勃勃搞起模板元编程从入门到放弃;预处理的伪图灵完备也玩出翔来;将mfc操得体无完肤;对stl、boost也深挖祖坟以至深感失望(stl还好,boost真心烂);C++编译器也被操得死去活来;……,这都有多少年过去了,依然感觉写不好C++代码,依然充满疑惑,代码写来写去,总是感觉写的不对,似乎还可以提升,还可以提升,可以在牺牲性能、类型安全、弹性、易用性的前提下继续加强性能、类型安全、弹性、易用性,你不知道C++的上限在哪里。直到有一天,那一刻,终于到达彼岸。

对于普通用户来说,C++最大的问题,就是缺乏一个高水准高质量的基础通用库,这个库,首先要坚持住零惩罚抽象的底线,不管怎么样,都不得妥协,历史的经验证明,在这一点上退缩的基础库,最后都将导致整个设计框架上的冗余,倒不仅仅只是因为性能的原因。其次,在性能、弹性、使用接口、类型安全等综合方面都要取到很好的平衡点,也就是说用这个库说人话的时候,其性能一定要不差,好用,有弹性,类型上用得不对,编译器就不满意。但是这个基础库又要像大C++语言本身一样,充满后门,只要愿意,随时都可以为了提升某一要素,可以牺牲任何其他要素(比如说为了性能,将使用接口、弹性上搞得很难看)。具体展开来说,这个基础库包括,完备的内存管理(支持一定程度的gc效果,其实就是多次分配,一次统一释放);完备的运行时类型信息;极大地挖掘template的潜力;编译期与运行期的无缝对接,二进制语义上的清晰。至于再具体来说,比如字符串设计,格式化,序列化,IO,侵入式的容器,迭代器,协程等,就是细微末节了。

显然,以上述的要求来评判stl,显然stl很不行的,虽然勉勉强强坚持住零惩罚的底线,但是总体来说,其性能、弹性、使用接口、类型安全的总体分数上是相当低的。1、竟然脑洞大开,将内存管理当做是容器的类型参数来操作,这样玩的严重可怕后果,就不说stl的东西不能很好地用于动态库,想要做有gc效果的内存管理也不好办了;2、对模板的使用只停留在很低的层次上,本来可以提供更多更有力的抽象机制,比如非侵入式接口,比如消息,比如异构容器;3、回避虚函数,回避反射,导致stl的运行时类型信息很薄弱,进而导致垃圾的io stream实现,对面向对象的支持极差,也导致痛苦漫长的编译过程;4、对于编译期的丰富类型信息,只会用类型拭擦一招带到运行期,导致到运行期时丢失了很多重要的信息;5、对于容器的二进制布局,回避,不花心思,所以二进制的复用效果很差;……,算了,对stl的不满,简直是说三天三夜也说不完。所以,以stl为基础来写代码,能不一再反复造轮子,写代码能愉快?

所以,C++的难,说到底,只是通用基础库的实现之难。C++的难,是C++专家的难题,并非普通用户的麻烦。那么,实现通用基础库的难度有多大,从C++面试至今三十多年,还没出现过,你说会有多难呢?那么,为什么会这么难呢?

一直以来,C++专家对C++的认识,一直停留在很低的层面上。面对着C++复杂庞大的类型系统,完全开放式的内存管理,直接操作机器的种种方便,威力无比的template,很丑陋又好像很重要很有作用的预处理,厚颜无耻的多继承以及不定时炸弹的异常,这些东西造就了C++无限可能的同时,也造成了C++在打造基础通用的极大困难。表面上存在无穷无尽的选择,但是正确的路子,真心不多。一不小心,就面临无穷无尽的细节上的考究,最后造出来的轮子,反而引入更多的麻烦。而更糟糕的是,很多人更高估了自己对C++的认识,贸贸然就随随便便造轮子,还大规模的在代码上到处泛滥。(待续)