C++之父谈C++语言设计规则( 二 )


4.1 规则和原理要成为真正有用而且人们乐于使用的东西 , 一个程序设计语言的设计就必须有一种全局观 , 用于指导语言中各种特征的设计 。 对于C++ , 这种全局观由一组规则和约束构成 。 称其为规则 , 是因为我认为把原理这个词用在一个真正的科学原理非常贫乏的领域 , 显得过于自命不凡 , 而程序设计语言设计就是这样一个领域 。 此外 , 对许多人而言 , 术语原理隐含着一个不太实际的推论 , 也就是说 , 任何例外都是不可接受的 。 而我的有关C++设计的规则几乎可以保证都有例外情况 。 实际上 , 如果一条规则与某个实际试验发生冲突 , 这个规则就应该靠边站 。 这样说 , 看起来似乎有些粗鲁 , 但是它不过是一条一般性原则的变形:理论必须与试验数据相吻合 , 否则就应该被更好的理论取代 。
这些规则绝不能不加思索地使用 , 也不能用几条肤浅的口号取代 。 我把自己作为一个语言设计者的工作看作去决定需要对付的是哪些问题 , 决定在C++ 的框架里能够对付的是哪些问题 , 并在实际语言特征设计的各种规则之间保持一种平衡 。
这些规则指导着与语言特征有关的各项工作 。 当然 , 改进设计的大框架是由C++ 的基本设计目标提出来的 。
我把这些规则组织在四个更具概括性的小节里 。 4.2节包含所有与整个语言有关的规则 , 这些东西非常具有普遍性 , 单个的语言特征将无法直接放进这个图景里 。 4.3节的规则基本上与C++ 在支持设计方面所扮演的角色相关 。 4.4节的规则关注与语言的形式有关的各种技术细节 。 4.5节的规则集中关注C++ 作为低级系统程序设计语言所扮演的角色 。
C++之父谈C++语言设计规则文章插图
这些规则的形式主要得益于事后的思索 , 但有关规则及其所表达的观点 , 在1985年C++的第一个发布之前就已经支配着我的思想了 , 而且——正如前面章节里讲到的——这些规则中不少还是C with Classes的初始概念的组成部分 。
4.2 一般性规则最一般和最重要的C++ 规则与语言的技术方面没太大关系 , 这些规则几乎都是社会性的 , 其关注点是C++ 所服务的社团 。 C++ 语言的本质在很大程度上出于我的选择 , 我认为它应该服务于当前的这一代系统程序员 , 支持他们在当前的计算机系统上解决当前遇到的问题 。 最重要的是 , 当前这个词的意义和性质总随着时间而变化 , C++ 必须能够发展 , 以满足其用户的需要;它的定义不应该是一成不变的 。
C++之父谈C++语言设计规则文章插图
C++ 的发展必须由实际问题推动:在计算机科学中 , 就像在许多其他领域一样 , 我们总能看到许多人在努力为他们最喜爱的解决办法寻找问题 。 我不知道有任何简单明了的方法能避免时尚扭曲我对什么最重要的认识 , 但是我也很敏锐地意识到 , 提供给我的许多语言特征在C++ 的框架里根本就不可行 , 它们常常与真实世界的程序员无关 。
改变C++ 的正确推动力 , 是一些互相独立的程序员证明该语言不能很好地表述他们的项目 。 我偏爱来自非研究性项目的信息 。 无论何时只要可能 , 在努力发现问题和寻找解决办法时 , 我设法与真实的用户联系 。 我如饥似渴地阅读程序设计语言文献 , 寻找对这些问题的解答 , 以及各种可能有帮助的技术 。 但是我也发现 , 文献在考虑真正的问题方面完全不可靠 , 理论本身不可能为加入或去掉一个特征提供充分的证据 。
不被牵涉到无益的对完美的追求中:任何程序设计语言都不是完美的 。 由于问题和系统都在持续变化 , 将来也不可能有完美的语言 。 用许多年功夫去修饰一个语言 , 希图去接近某种完美的概念 , 只能是使程序员无法从那些年的进步中获益 , 也使语言设计者不能得到真实的反馈 。 没有适当的反馈 , 一个语言就会逐渐与时代脱节 。 不同环境里的问题 , 各种计算机系统 , 以及——最重要的——人与人之间 , 都存在巨大的差异 , 因此 , 对某些小环境的“完美配合”几乎可以确定是过分特殊的 , 与大千世界的繁荣没多大关系 。 另一方面 , 程序员花费了他们的大部分时间去修改老代码 , 或者与它们接口 。 为了完成实际工作 , 他们需要某种稳定性 。 一旦某个语言投入了实际应用 , 对它的剧烈修改就不可行了 , 甚至想做一点小修改而又不伤害到用户 , 也是很困难的 。 因此 , 重要的改进需求必须依靠真实的反馈 , 并伴以对兼容性、转变过程和教育的认真考虑 。 随着语言逐渐成熟 , 人必须更多考虑通过工具、技术和库的替代性方式 , 而不是去改变语言本身 。


推荐阅读