用C计划 用C++编码[VC/C++编程]

《不得不看的两次从C++回归C的高手评论C++》中先是提了一下所谓C++带来的思惟负担（文言文曰“心智负担”）问题,然后重重地引用了Linus的话:“关键是计划”,其实他是在表示:好的计划C一样能做出来,不劳C++大驾;而C++一旦出头,就要让人背上额外的思惟负担.

我明确地表个态,在系统级程序计划中,事实就是这样的.

别藐视这个思惟负担,大部份,乃至绝大部份C++程序员过不了这一关.相反,做系统级开辟,C是几近没有思惟负担的语言,说白了就是刺刀见红,你想要啥你就去写啥,它给你的不多也不少,没什么干不了,也没什么非让你背着不可.

我早在N年前就发现自己写程序速度慢,我当时对STL远比四周人熟习,按例说长缨在手,应当效率很高才对.后果发现不是,写程序的时刻分外没自大,总在想:“这样当然是可以work了,但恐怕有更好的筹划吧!会是什么呢?加个模板参数试试?要末抽象出一个基类?做一个bridge情势?那么Ownership的问题怎么办理?谁来负责回收内存呢?移植一个boost::shared_ptr过来吧!可多线程情形下会不会拖慢速度呢?应当不会,但是会碰到循环引用的情形.要末在中间搞一个weak_ptr把循环链断开?哎呀!不行不行,太复杂,别人也理解不了.还是先这样吧!能work就行.”就这样,兜了一个圈子回来.有的时刻,这个圈子不是纯柏拉图式的,我会真的实现不少“优化”计划来比对,那个时间啊!花花的就耗在里面了.有的时刻确切会得到一些改良,但是大都时刻是得不偿失,旁边那些在我看来连C都只是一知半解的家伙采取“CtrlC-CtrlV-Modify-Debug”办法,早就冲到我前头去了.这就是“心智负担”的威力.

近来几年没怎么用C++写程序,业余时间倒是别的语言用了好几种.大约是领会到这些语言的某些好处之后,对C++就可以看得更客观一些了,也琢磨了一下,假如自己有朝一日重新跑回去写C/C++,我会怎么干?毕竟目前C++程序员环球紧缺,工资越来越高,这个问题还是有其实际意义的.恰好跟chensh 聊了一会儿,两个人的见解一致,就是采纳“ C + Concreate Class + STL”的气势.说白了就是用C来计划,用C++来编码.

这里面的原理是这样的,反正目前C和C++都是来做系统级开辟,那些富丽的抽象机制用不上,考虑办理筹划的时刻,就以C的方法.注意,C也是可以做基于对象乃至面向对象乃至组件级别的计划的,但是在C的层面上考虑问题,计划可以更精益（lean,目前这是个时髦词）,更简便,更直接.当你假想的计划筹划出来今后,假如此中有些部份,刚好是C++现成做好了,并且利用C++又可以提高开辟效率,也没什么明显的副作用,那么就用C++来做呼应的部份.比方,COM本来计划的时刻就是在C底子上做的,计划的时刻发现实际上跟C++实现多态的的vptr + vtable是符合的,所今后来就主要用C++来做COM开辟.事实上,为了适应COM开辟的需求,微软直接改了C++编译器.很明显,微软是首先假想好的计划,然后让C++去适应这个计划.此后来很多C++程序员,是让计划去适应C++的那些语言机制,在系统开辟中,这个叫做本末倒置.当然这样的事情在利用级别上就不是那么离谱.

实际上回头看看C++早期的历史,最早C++就是把一些C中常用的patterns内置到语言里而呈现的,早期它曾经有效地提高了开辟效率.本日应当回头去探求这种精神.

我支持STL是基于一样的来由.很多时刻,你从C动身得到的计划,也无非就是STL已经实现得很好的东西.在这个时刻,当然可以用STL.特别是那些算法,针对C array也是实用的,用accumulate求和,用transform映射,用adjacent_find探求相等的毗邻项,用lower_bound和equal_range做二分查找等等,这不是比手写要爽多了吗?当然,利用STL,还是必须熟习其背后的机理,没有这个底子,还是规行矩步用C算了.