《Effective C++》读后感

从八月初在当当上订上这本书，到现在九月初把这本书粗粗读完一遍，期间大概一个月时间，平均每天读一个条款多一点。基本上，每个条款，除了个别的细节外，都能读明白，大致上也都知道“所以然”。但是，如果现在让我合上书，写上一段代码，恐怕这些理解还显得肤浅——毕竟”看“和”写“是两码事，程序员归根结底还是要去”创造“的。

全书55个条款，可以看成55节，分为9章，作者的语言相对平实，思维有些跳跃，而且主要是以“问题”的形式去讲述，有些章节还要再去翻《C++ Primer》这样的书。侯捷的翻译相对还算准确（大致感觉），有些翻译有点拗口，有些也有些不恰当，这里就不记了。

个人最感兴趣的还是关于设计这三章（第4章：设计与声明，第5章：实现，第6章，继承与面向对象设计），这几章浅显易懂，读起来也更流畅，最主要的还是当下手编程时非常实用。作者所提的关于虚函数的声明，关于派生类中函数的重写等等，都与这些内容紧密相关。

模板与泛型编程这一块，以前从来没有接触过，只是知道模板的引入可以大大提高代码的通用性，但是当作者指出C++模板系统可以当作一个图灵机真的让我惊艳了一把。得益于C++的命名系统，模板在编译期的特化过程可以实现出分支与循环（递归）语句，给代码的最终生成带来了很大的灵活性。

当然，印象最深的，还是作者一遍又一遍苦口婆心地强调C++的命名规范和内存管理：前者，C++作为一个强类型语言，加上面向对象特性（类）的加入，使命名规范（包括类型转换）成为一个难以理解更难于驾驭的特性；后者，作为继承自C语言的能够直接操作内存的语言，内存泄漏就像地雷一样让人防不胜防，以至于历来的C++大牛们，花费了大量心血在防范内存分配错误这个问题上，设计出诸如智能指针、operator new甚至Boost程序库中的pool。诚然，对于像Java和C#这样的语言来讲，内存分配只是个概念，虚拟机会自动对程序实行“垃圾回收”，而C和C++这样的手工管理方式虽然带来了极高的运行效率和灵活性，同样也带来了极大的危险性。是的，从这方面来说，C++永远是危险的，而C++程序员就如同在薄冰起舞。

关于C++与其他面向对象语言（如Java）孰优孰少的争论由来已久，网上也时不时有人拿出来炒冷饭，而每次也都沦为双方的口水战，论点也都是一成不变的诸如效率的那些说辞。除去那些意气之争，大家都同意的看法是：对于一个“软件开发人员”来说，Java或者C#就足够了，程序员完全可以把自己的目光集中在软件的外部行为上。论开发效率，两者应该都比C++高，丰富的程序库和设计更为精良的”面向对象体系“（不得不说C++在面向对象特性上表现得还有点原始）使得它们构建起一个方便快捷的生态系统；至于运行效率，对于一个普通的软件来说，完全可以信任Java虚拟机的设计者和硬件性能的提高。但是，对于“系统开发人员”来说，Java之流恐怕就有点力不从心了；另外，对于对效率要求得太高，以至于去逼近硬件发挥出最大潜力的程序，比如不断推动PC硬件更新换代的电脑游戏，比如支撑系统运行的那些底层，比如包括Java虚拟机这样的“中间件“，C或者C++就是必须的了。

我从大二开始自学C++，研一时想重新拾起这个爱好深入学习计算机时，久久想如何选择开发语言。我喜欢C++的”底层“属性，这或许和我的物理专业背景有关，两者都试图从最基本的原理搭建出整个世界。不选择C语言是因为在这个随便编个程序就得几百行的时代，用C写程序太费劲了，缺乏”设计模式“和相对成熟的开发库（Linux下倒是有一整套的开发框架，但是移植性不好）。我是从“界面编程”开始考虑的，如果一门语言或者开发框架连基本的图形界面都难以生成，那就太不“实用”了。一开始想学微软的VC++，从而看上了MFC框架，学了一段时间发现MFC其实是半C半C++的，而且架构相当混乱，网上说连微软都不想支持这东西了，从而动力大减；这本书里讲了一个画图程序的实现例子，可是我跟着书写了一个月，越写越糊涂，写到最后连自己都不知道这些函数为什么要加进去，那些变量为什么声明得那么繁琐，还有哪里来的几十个又长又难懂的宏，从而彻底作罢。

这时我开始关注其他的C++开发框架，偶尔发现了Qt，它架构成熟，使用方便，同时移植性好，不仅能够在Windows和Linux平台上迁移，甚至是嵌入式开发的不二人选。学上一段时间，发现它真的很适合我这样一个没有任何基础的人。现在Qt的学习基本上已经入门，正在啃一些软件开发的框架，有时间会将Qt的学习心得记在这里。

网上列举的C++学习书单，大致看来有这些，读过的只有这本Effective C++和C++ Primer，计划一本本读完。