C++设计目标和原则_C/C++教程

一、 C++的设计目标（C++ Design Aims）

　　C++的设计目标，就是要让C++既具有适合于系统程序设计的C语言所具有的可适应性和高效性，又能在其程序组织结构方面具有像Simula那样的语言设施（Simula所支持的这种程序组织结构通常被称为面向对象程序设计风格）。在设计的时候，还做了很大的努力，使得引借自Simula的高层次的程序设计技术能够应用于系统程序设计之中。这即是说，C++所提供的抽象机制能够被应用于那些对效率和可适应性具有极高要求的程序设计任务之中。

　　上述的C++之设计目标可以小结如下：

　　对于要解决实际问题的程序员而言，C++使程序设计变得更有乐趣；C++是一门通用目的的程序设计语言，它：

　　——是一个更好的C；

　　——支持数据抽象；

　　——支持面向对象程序设计；

　　——支持范型程序设计。

　　对范型程序设计的支持在C++设计的后期才被作为一个明确、独立的目标来实现。而在C++演化过程的大部分时间里，我一直把范型程序设计以及支持它的语言特性划归在“数据抽象”的大标题之下。　　二、 C++的设计原则（Design Principles）

　　在[Stroustrup,1994]中，C++的设计规则被分为基本规则、基于设计的规则、语言的技术性规则以及基于低层次程序设计的规则四个方面，分列在下文中。　　[基本规则（General rules）]

　　A:　C++的每一步演化和发展必须是由于实际问题所引起的；

　　B:　C++是一门语言，而不是一个完整的系统；

　　C:　不能无休止的一味追求完美；

　　D:　C++在其存在的“当时”那个时期必须是有用处的；

　　E:　每一种语言特性必须有一个有根据的、明确的实现方案；

　　F:　总能提供一种变通的方法；

　　G:　能为意欲支持的每一种程序设计风格提供易于理解的支持方法；

　　H:　不强制于人。

　　可以注重到，基本规则的最后三条暗示了两点：对适用于真实世界中各种应用的便捷工具的强调；对程序员的技术和取向（偏好）的充分考虑。从一开始，C++面向的就是那些要做实际项目的程序员。所谓的“完美”被认为是不可能达到的，这是由于C++用户在需求、背景和待解决问题上存在着太大的不同。况且，在一门通用目的的程序设计语言的整个生存期之内，连对“完美”一词的诠释都可能会有极大的改变。由此可知，在语言的演化过程中，来自用户的反馈和语言实现者们积累的经验才是最为重要的。
　　[基于设计的规则（Design-support rules）]

　　A:　支持良好的设计方案；

　　B:　提供用于程序组织的语言设施；

　　C:　心口如一（Say what you mean）；

　　D:　所有的语言特性必须具有切实有效的承受能力；

　　E:　开启一个有用的特性比避免所有的误用更为重要；

　　F:　能将独立开发的部件组合成完整的软件。

　　C++的一个目标就是提供更易用并具有一定承受能力的设计思想和程序设计技术，进一步提高程序的质量。这些技术中的绝大部分都源自Simula ，并通常被作为面向对象程序设计和面向对象设计思想来讨论。然而，C++的设计目标总还是在于要支持一定范围内的各种程序设计风格和设计思想。这与一般在语言设计方面的观点形成一定对比。一般在语言设计上总是试图将所有系统内建于单独一个被重点支持的、带有强制性的程序设计风格之中（或称典范paradigm）。　　[语言的技术性规则（Language-technical rules）]

　　A:　与静态型别系统（Static type system）没有内在的冲突；

　　B:　像对内建（built-in）型别一样对用户自定义型别提供很好的支持；

　　C:　个异化（locality）行为是可取的；

　　D:　避免产生顺序上的依靠关系；

　　E:　在对语言产生迷惑时，可以选取其特性中最易把握的部分；

　　F:　可以因为不正当的语法使用而产生问题（Syntax matters (often in perverse ways)）

　　G:　削弱对预处理器的使用。

　　当然，这些规则要具体结合更多关于基本目标的上下文环境来考虑。应该注重到的是，在“与C有较高的兼容性”、“不损失效率”以及“具有便捷的可用性来解决实际问题”这三个方面的要求，与在“完整的型别安全性”、“完全的通用性”以及“完善的抽象之美”这三个方面的要求形成对立。

　　C++从Simula中借鉴了用户自定义型别和类层次机制。然而，在Simula及许多类似的语言中，其对用户自定义型别的支持与其对内建型别的支持存在着根本上的不同。例如，Simula中不答应在栈中为用户自定义型别的对象分配空间，并且只答应通过指针（这在Simula中称为引用——reference）来对这些对象进行访问。而相反的，内建型别的对象只在栈中被分配空间，不能在动态存储区中分配，而且不能使用指针指向它。这种在对待内建型别与对待用户自定义型别上的差异，暗示着对效率问题的严格考虑。比如，当作为一个在动态存储区中被分配的对象之引用时，假如该对象属于自定义型别（比如complex），那么就会为运行期及空间带来负荷；而这些负荷在有些应用中被认为是不可接受的。这些正是C++意欲涉足解决的问题。同时，在用法上的不同也决定了：不可能在范型程序设计中统一对待那些语义上近似的型别。

　　在维护一个较庞大的程序时，一个程序员不可避免的会基于某些不完整的知识来对程序作一些修改，只关注全部程序代码中的一小部分。基于此，C++提供了class、namespace和访问控制，使设计决策的各异化（locality）成为可能。
　　在基于一趟编译（one-pass compilation）的语言中，某些顺序上的依靠性是不可避免的。例如在C++中，一个变量或者函数在其被声明之前是无法使用的。然而，C++中类成员的名字规则和重载解析（overload resolution）的规则还是在独立于声明顺序的原则下被制定出来，以便将发生混乱和错误的可能性降至最低。

　　[基于低层次程序设计的规则（Low-level programming support rules）]

　　A:　使用传统的（笨拙的）连接器（linker）；

　　B:　与C语言不存在无故的不兼容性；

　　C:　不给C++之下层级的更低层语言留出余地（汇编语言除外）；

　　D:　你不会为你所不使用的部分付出代价（零负荷规则）；

　　E:　在产生迷惑时，能提供完全自主控制的途径。

　　在C++的设计中只要在不严重影响其对强型别检查（strong type checking）的支持的地方，都尽量做到与C的“source-link”方式相兼容。C++与C的兼容性使得C++程序员马上就能有一个完整的语言和工具集可用。还有两点也很重要，一是有大量关于C的高质量的教学素材已经存在，二是C++程序员可以利用C++与C的兼容性而直接并有效的使用大量现成的程序库。在决定将C作为C++的基础的时候，C还没有像后来那样出类拔萃、炙手可热，所以在考虑这个问题的时候，与C语言所提供的可适应性和高效性相比，C语言的流行程度只是个次要的考虑因素。

　　然而，与C的兼容性也使得C++在某些语法和语义上保留了C的一些瑕疵之处。比如，C语言的声明语法就实在远不及美丽；而其内建型别的隐式转换规则也是混乱无章法的。还有另一个大问题，就是许多从C转向C++的程序员并没有熟悉到，代码质量上的显著提高只能通过在程序设计风格上的显著改变来达到。