书读完了

上周在家读《Effiective C++》，一气呵成，差点一天就把这本书读完了，自己都吃了一惊。

语言之争之前聊过一些，这次读着读着，突然觉得很无聊。有的人认为，语言只是一种工具；但我一直不认同这个观点，语言影响着你的表现力的上限。虽然到最后，其实无非就是if-else和loops，但是这些if-else和loops如何组织，其实和所使用的语言有很大的关系。

这次读书我只是感觉C++为了封装特性加入了很多语法糖。比如继承，虚函数，public/private的限制器。之前我一直认为其实C++就是把创造类型作为了一大设计目标，自己创造的类型和语言自带的类型的地位是几乎相同的，当然这要付出巨大的复杂度代价，一个基本类型如何构造，如何析构，如何赋值，运算符重载等等，语言都提供了设计工具。但其实，实际使用中还是不能抹平这个差异。其实就看你要抠到什么程度，差异本身就存在，构造一个int和构造一个struct在内存上的压力显然是不可能相等的。

所以简单来说，还不如不提供这些工具，让程序员自己操心构造和析构。表面上RAII让程序员不用操行这些，但实际上一旦要更精细的控制，就只能更加恶心，比如在多线程情况下的构造，一般都需要二段式，先构造一个弱智版，然后再调用成员函数，加锁完成第二次的构造。所谓mental burden估计就是这个意思，又要用到编译器自动生成的代码，又想做更多的控制和调整（比如move语意），搞得无比复杂，其实最后无非就是把指针从A的壳子移动到B的壳子里。

但是有时候不依赖这些，直接写直白的代码，也会将代码搞的比较晦涩。plain C code的坏处在于，无法理解作者的设计意图，我们只看到机械的一个函数调用另一个函数，但是很难看到整体的架构。C++会好一点，在他本身设计的好的领域里，比如OO，如果用C++写，就会比较清爽。不过稍微复杂的C++，其实如果不了解惯用法，也会看着一头雾水，其实就是每个字都认识，每个class你都能读懂意思，但是整体中心思想还是没懂。这一点在所谓的meta programming上体会颇深。因此这次读《Effective C++》尤其是模板那一节就发现，之前读了好多code，原来是因为这个原因要写成那样。

读完《Effective C++》之后，感觉如果要继续，可以先试着写点代码了，书读完了，这本书上的经验足够用很久很久了。

其实渐渐的，感觉对C++也在去魅。慢慢的，我开始怀疑，其实没有什么东西能比的上熟悉，如果你熟悉C，其实很多时候，其工程效率和C++未必有那么大差别。

最近一段时间的感触很多，不一定是技术的，而是发现之前很多感觉很神秘的东西，一旦了解深入之后，发现很多，要么就是一些媒体宣传，要么就是过于曲高和寡的艰涩技术，在具体实践中，往往可以通过一些方式绕开。编程，说到底，其实不过就是if-else和loops而已。