C++之父谈C++语言设计规则( 四 ) .font_s.ios.pgcarticle

为每种被支持的风格提供全面支持：C++ 必须为满足严肃的开发者们的需要而不断发展。简洁是最基本的东西，但应根据将要使用C++ 的项目的复杂性来考虑这个问题。与保持语言定义比较简短相比，用C++ 写出的系统的可维护性和运行时的性能是更重要的问题。这实际上意味着要做的是一个规模相对较大的语言。
这也意味着——正如许多经验所说明的——必须支持各种风格的程序设计。人们并不是只写那些符合狭义的抽象数据类型或者面向对象风格的类，他们也要写同时具有两方面特点的类，这样做通常都有很好的理由。他们还会写这样的程序，其中的不同部分采用了不同的风格，以适应具体需要或者是个人口味。
因此，语言特征应该设计成能以组合的方式使用，这也导致了C++ 设计中相当程度的正交性。支持各种“非正常”使用的可能性，对于灵活性提出了很高要求，这已经一再地导致C++ 被用到一些领域中，在那里，更局限更专注语言可能早就失败了。例如， C++ 中有关访问保护、名字检索、virtual / 非virtual约束，以及类型的规则都是相互独立的，这样就打开了一种可能，同时使用依赖于信息隐蔽和派生类的各种技术。有些人愿意看到一贯语言只支持很少几种程序设计风格，他们会认为这里的做法是“黑科技” 。在另一方面，正交性并不是第一原则，只有在其不与其他规则冲突，既能提供某些利益而又不使实现复杂化的时候，我们才采纳它。
做一种相对较大的语言，也意味着在复杂性管理方面的努力需要有所转移，从对于库和个别程序的理解方面，转到学习语言及其基本设计技术。对大部分人而言，这种重点转变，对新程序设计技术的采纳，对“高级”技术的使用，都只能逐步完成。很少人能够“一蹴而就”地完全掌握新技术，或者一下就能把所有的新招术都用到自己的工作里（7.2节）。 C++在设计中考虑了如何使这种渐变成为可能的和自然的。这里的基本思想是：你不知道的东西不会伤害你。静态类型系统和编译的警告信息在这方面非常有帮助。
不试图去强迫人做什么：程序员都是很聪明的人，他们从事挑战性的工作，需要所有可能的帮助，不仅是其他支撑工具和技术，也包括程序设计语言。试图给程序员强加严格的限制，使他们“只能做的正确事情” ，从本质上说是搞错的方向，也注定会失败。程序员总能找到某种方法，绕过他们觉得无法接受的规则和限制。语言应该支持范围较广泛的、合理的设计和编程风格，而不应该企图去强迫程序员采纳某种唯一的写法。
当然，这并不意味着所有的程序设计方式都同样好，或者说C++ 应该支持所有种类的程序设计风格。 C++ 的设计是为了直接支持那些依靠广泛的静态类型检查、数据抽象和继承性的设计风格。当然，关于应该使用哪些特征的训教被维持到最小的程度。语言机制尽可能保持了一种自由的政策，没有专门为了排斥任何确定的程序设计风格，而向C++ 里加进或者从中减去一种特征。
我也很清楚地意识到，并不是每个人都赞赏选择和变化。无论如何，那些偏爱带有较多限制环境的人，可以在C++ 里始终如一地坚持使用某些规则，或者去选用另一种语言，其中只给程序员提供了很少的一组选择。
许多程序员特别反感被告之某种东西可能是一个错误，而实际上它并不是。所以， “可能的错误”在C++ 里并不是一个错误。例如，写一个能允许歧义使用的声明本身并不是错误，错的是那些存在歧义性的使用，而不只是这个错误的可能性。按照我的经验，多数“潜在错误”根本不会显现出来，因此推迟错误信息的方式就是不把它给出来。这种推迟也会带来许多方便和灵活性。
4.3　设计支持规则列在这里的规则主要讨论C++ 在支持基于数据抽象和面向对象程序设计方面扮演的角色。也就是说，它们更多关注这个语言在支持思考和表达高层次思想方面扮演的角色，而不是它按C或Pascal的方式，作为一种“高级汇编语言”时扮演的角色。