从C语言开发到C++开发的技术人员们没有想到的是，代码质量上的显著提高只能通过在程序设计风格上进行改变，对于C++兼容性问题，一个变量或者函数在其被声明之前是无法使用的。
C++的每一步演化和发展必须是由于实际问题所引起的；C++是一门语言，而不是一个完整的系统；不能无休止的一味追求***；C++在其存在的“当时”那个时期必须是有用处的；
每一种语言特性必须有一个有根据的、明确的实现方案；总能提供一种变通的方法；能为意欲支持的每一种程序设计风格提供易于理解的支持方法；不强制于人。可以注意到，基本规则的***三条暗示了两点：
对适用于真实世界中各种应用的便捷工具的强调；对程序员的技术和取向（偏好）的充分考虑。从一开始，C++面向的就是那些要做实际项目的程序员。所谓的“***”被认为是不可能达到的。
这是由于C++用户在需求、背景和待解决问题上存在着太大的不同。况且，在一门通用目的的程序设计语言的整个生存期之内，连对“***”一词的诠释都可能会有极大的改变。由此可知，在语言的演化过程中，来自用户的反馈和语言实现者们积累的经验才是最为重要的。
支持良好的设计方案；提供用于程序组织的语言设施；心口如一（Say what you mean）；所有的语言特性必须具有切实有效的承受能力；开启一个有用的特性比避免所有的误用更为重要；
能将独立开发的部件组合成完整的软件。C++的一个目标就是提供更易用并具有一定承受能力的设计思想和程序设计技术，进一步提高程序的质量。这些技术中的绝大部分都源自Simula [Dahl,1970][Dahl,1972][Birtwistle,1979]，并通常被作为面向对象程序设计和面向对象设计思想来讨论。
然而，C++的设计目标总还是在于要支持一定范围内的各种程序设计风格和设计思想。这与一般在语言设计方面的观点形成一定对比。一般在语言设计上总是试图将所有系统内建于单独一个被重点支持的、带有强制性的程序设计风格之中（或称典范paradigm）。
与静态型别系统（Static type system）没有内在的冲突；像对内建（built-in）型别一样对用户自定义型别提供很好的支持；个异化（locality）行为是可取的；避免产生顺序上的依赖关系；在对语言产生疑惑时，可以选取其特性中最易掌握的部分；
当然，这些规则要具体结合更多关于基本目标的上下文环境来考虑。应该注意到的是，在“与C有较高的兼容性”、“不损失效率”以及“具有便捷的可用性来解决实际问题”这三个方面的要求，与在“完整的型别安全性”、“完全的通用性”以及“完善的抽象之美”这三个方面的要求形成对立。
C++从Simula中借鉴了用户自定义型别（class,§4.1）和类层次机制。然而，在Simula及许多类似的语言中，其对用户自定义型别的支持与其对内建型别的支持存在着根本上的不同。例如，Simula中不允许在栈中为用户自定义型别的对象分配空间，并且只允许通过指针（这在Simula中称为引用——reference）来对这些对象进行访问。而相反的，内建型别的对象只在栈中被分配空间，不能在动态存储区中分配，而且不能使用指针指向它。
这种在对待内建型别与对待用户自定义型别上的差异，暗示着对效率问题的严格考虑。比如，当作为一个在动态存储区中被分配的对象之引用时，如果该对象属于自定义型别（比如complex,§4.1），那么就会为运行期及空间带来负荷；
而这些负荷在有些应用中被认为是不可接受的。这些正是C++兼容性解决的问题。同时，在用法上的不同也决定了：不可能在范型程序设计中统一对待那些语义上近似的型别。
在维护一个较庞大的程序时，一个程序员不可避免的会基于某些不完整的知识来对程序作一些修改，只关注全部程序代码中的一小部分。基于此，C++提供了class（§4）namespace（§5.2）和访问控制（§4.1），使设计决策的各异化（locality）成为可能。
在基于一趟编译（one-pass compilation）的语言中，某些顺序上的依赖性是不可避免的。例如C++兼容，一个变量或者函数在其被声明之前是无法使用的。然而，C++中类成员的名字规则和重载解析（overload resolution）的规则还是在独立于声明顺序的原则下被制定出来，以便将发生混乱和错误的可能性降至***。
【编辑推荐】
