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


这个规则在C++的设计决策中不断成为最关键的考虑 。 虚函数(3.5节)、多重继承(12.4.2节)、运行时的类型识别(14.2.2.2节)、异常处理和模板 , 都是与此有关的特征实例 , 它们的设计也部分地可以归于这条规则 , 都是到了我自己已经确信能构造出遵守0开销规则的实现方式时 , 这些特征才被接受进来 。 当然 , 一个实现者可以决定在0开销规则和系统所需要的某些性质之间如何做一种折中 , 但是也必须仔细地做 。 程序员通常对于分布式的增肥会有刺耳的、非常情绪化的反应 。
如果想拒绝人们建议的一个特征 , 0开销规则可能是所有规则中最锋利的一个 。
遇到有疑问的地方就提供手工控制的手段:我对信任“高级技术”总是非常勉强 , 也特别不愿意去假定某些真正复杂的东西是普遍可用的和代价低廉的 。 inline函数是这方面的一个很好的例子(2.4.1节) 。 模板初始化是另一个例子 , 我在那里应该更当心一点 , 后来又不得不增加了一种显式控制的机制(15.10节) 。 对存储管理的细节控制也是一个例子 , 通过手工控制可能得到重要的收获 , 然而 , 只有时间才能告诉我们这些收获是不是可以通过某种自动化技术以类似的代价得到(10.7节) 。
4.6 最后的话对于各种主要的语言特征 , 所有这些规则都必须考虑 。 忘掉任何一个 , 都很可能带来某种不平衡 , 从而伤害到一部分用户 。 与此类似 , 让某个规则成为主导而损害其他方面 , 同样可能带来类似的问题 。
我试着把这些规则都陈述为正面的命令式的句子 , 而不是构造出一个禁止表 。 这可以使它们从本质上说更不容易被用于排除新思想 。 我对C++ 的观点是 , 它是一种生产软件的新语言 , 特别关注那些影响程序结构的机制 。 与只做一些小调整的自然倾向相比 , 这种观点走的完全不是同一条路 。
ANSI/ISO委员会工作组对语言的扩充提出了一个检查表(6.4.1节) , 那是对一个语言特征应该考虑的问题的更特殊、更细节的描述 。
[1] 笨(dumb)连接器 , 指那些传统的最基本的 , 不提供任何特殊功能的连接器 , 也就是一般的系统上普遍使用的连接器 。 ——译者注
本文摘自C++语言之父jarne Stroustrup的经典著作《C++语言的设计和演化》 。
C++之父谈C++语言设计规则文章插图
在传统上 , 关于程序设计和程序设计语言的书都是在解释某种语言究竟是什么 , 还有就是如何去使用它 。 但无论如何 , 有许多人也很想知道某个语言为什么会具有它现在的这个样子 , 以及它是怎样成为这个样子的 。 本书就是想针对C++ 语言 , 给出对后面这两个问题的解释 。 在这里要解释C++ 怎样从它的初始设计演化到今天的这个语言 , 要描述造就了C++ 的各种关键性的问题、设计目标、语言思想和各种约束条件 , 以及这些东西又是如何随着时间的推移而变化的 。
当然 , C++ 语言和造就它的设计思想、编程思想自身不会演化 , 真正演化的是C++ 用户们对于实际问题的理解 , 以及他们对于能够帮助解决这些问题的工具的理解 。 因此 , 本书也将追溯人们用C++ 去处理的各种关键性问题 , 以及实际处理那些问题的人们的认识 , 这些都对C++ 的发展产生了重要影响 。
C++ 仍然是一个年轻的语言 , 许多用户对这里将要讨论的一些问题还不知晓 。 这里所描述的各种决策的进一步推论 , 可能还需要一些年才能变得更清晰起来 。 本书要展示的是我个人关于C++ 如何出现、它是什么以及它应该是什么的观点 。 我希望这些东西能帮助人们理解怎样才能最好地使用C++ , 理解C++ 的正在继续进行的演化进程 。
书中特别要强调的是整体的设计目标、现实的约束以及造就出C++ 的那些人们 。 有关各种语言特征的关键性设计决策的讨论被放到了相应的历史环境里 。 这里追溯了C++ 的演化过程 , 从C with Classes开始 , 经过Release 1.0和2.0 , 直到当前ANSI/ISO的标准化工作 , 讨论了使用、关注、商业行为、编译器、工具、环境和库的爆炸性增长 , 还讨论了C++ 与C、Simula之间关系的许多细节 。 对于C++ 与其他语言的关系只做了简短讨论 。 对主要语言功能的设计 , 例如类、继承、抽象类、重载、存储管理、模板、异常处理、运行时类型信息和名字空间等 , 都在一定细节程度上进行了讨论 。


推荐阅读