上一篇中，主要是对C++类设计的一个概览。如果你认为那写得很肤浅，并能明确指出问题所在，那么恭喜你，可以说，你对C++的类机制有了更深入的了解！   

    这并不是说上篇笔记中有什么错误，前文仅仅就B.S.概述当中的某几句进行了适当的联想，但不能说全面、深入。其中提及的好多思想，方法只是针对C++类设计当中的类别：“具体类”的设计与实现。其他诸如层次结构的、多态的、范型的设计实现方法，可能不在此限，因为这是后续专题的主要任务。希望大家能够理解。

//---------------------------------------------------------------

  Tips：“简单而通俗的东西，从统计上来看，远比那些复杂而玄妙的东西重要的多。”  -- B.S.

    “使用类型系统去检查函数的参数，去保护数据不被意外地破坏，去提供新的类型，去提供新的操作，如此等等，这些在C++里都没有增加任何运行中的时间或者空间开销”[1]

         “C++设计的目的之一，是使一个平均行的C++代码能够表达出远比一个平均行的C或Pascal代码更多的东西。”[2]

         “一个声明了函数参数类型、使用了自定义类等机制的C++程序，通常比没有使用这些功能的等价C程序短一些；在那些使用了库的地方，C++程序就要比等价的C程序短的多。”[3]

1.4历史注记

         “……这个语言已经经过了广泛的审查和精炼。……所有这些扩充和修订的主旨都是为了是C++能够成为一个能更好编写、使用库的语言。”[4]

1.5 C++的使用

         “我认为C++不应在底层的效率上妥协，这就使我们有可能用C++写设备驱动程序、或者其他需要在实时约束下直接操作硬件的软件。”[5]

         这几句话分散在原书中的不同章节，我把它们放到一起是因为我觉得这几句话都是在讲一个事情：效率。作者反复含蓄、但也毫不退让的指出，C++无论其最初的设计目的还是最终的实践检验都从来没有向效率妥协过。C++的目的是为了能够保持C的执行效率的基础上而大大提高程序的开发效率、扩大语言所能处理问题的覆盖面。

         我也曾经动摇过，认为C++的优雅、高效的开发效率是与执行期间的效率进行妥协的产物，就好像java一样。可是作者明确的提出这是一种偏见。他曾说，C++完全可以胜任诸如驱动、操作系统以及对实时性要求很高的管理软件的任务。回顾我的第一个作品，我认识到，也许很多人都犯了与我相同的错误：把由于自己编程习惯、风格而造成的效率低下，归咎于C++语言本身。之所以这么说，是因为每次维护、修改我的第一个作品（这是一个商用软件）时候我都发现，当时为了在规定的时间内完成任务，而放弃良好的设计思想、以及优雅、严谨、高效的编程风格，是一件多么愚蠢的行为。我所付出的带价不仅仅是丑陋的代码，还有昂贵的后期维护开销（包括时间和金钱上的）。更可惜的是浪费了一次能够培养出思想与风格的机会。

         不扯远，还是说回效率。在那个不成熟的作品当中，我为了节省时间，而大量的使用了变量的按值存储、传递、返回等等。这些在一个release的大型的项目当中，所需要的系统开销简直是无法接受的。第一阶段的试验性的开发也许可以尝试，但是在成熟的作品当中都必需经过优化。如明确区分栈空间和堆空间；尽量使用引用机制和指针；以及一些函数算法、调用、返回等等许多方面的优化。

         C++完全兼容C，而且C的语言和思想是C++的最坚固的基石。这其中有另外一层意思也就是说C中执行的高效率思想也应该在C++中体现；诸如类机制、泛型设计以及模板只是一种C++语言为了提高开发效率所支持的几种语义表达方式。采用他们之前，我们应该再三问我们自己：“我要实现的任务是否确实需要用到这些高级的机制？如果需要，这种机制是否牺牲了执行期间效率？如果是，那么对于这种牺牲，我或我的客户是否可以接受？”我们不能够为了编程而编程，不能为了技巧而编程，我们基本的目标是：在尽可能短的开发周期里，用尽可能安全、简洁、高效的语言完成所规定的任务；稍微高层次的要求是我们应该提供最广泛的可适用性（或者说可扩展性），以及优雅的、易于维护的表达风格；最高层次的目的，则是在这一系列开发过程中，享受设计、创造的乐趣。

1.7 有关在C++里编程的思考

1.8 忠告

         读完这两节，我就一个字，“基本帅呆了”。大师就是大师，那种去繁就简、返璞归真不是一般速成的所谓高手能够装出来的；那种发自内心的、毫不做作的谦虚、包容的精神也愈发的令人敬仰。

         我在这两小节的旁白处只写下了这样一句话：“无论你是第几次翻开本书，都请再仔细研读本节！”