C 之父Bjarne谈C 中的STL模板

　在1994年，我主要关心的是如何使ISO C 标准尽可能地好--同时在他所包含的特性和规范的质量两个方面--并获得多数人的同意。即使人们不接受某种规范，也不会影响他（规范）的良好性。ISO标准没有强制力，因此有些人认为自己不值得浪费时间来适应他，除非（群体）社团的压力能够使他们确信该规范的价值。对于一个实现者来说，适应环境是很重要的额外工作，因此适应环境是个有意识的决定，并且需要分配一些资源，而这些资源本来能够在其他地方使用。某些晦涩的语言特性很难在某些编译器中实现。我们能够实现或购买类库，而且领先的、可靠的实现者（implementer）也有机会用自己的富于想像力的专利特性来"锁定"用户。因此，我认为要点是：让委员会成员和他们所代表的组织确信该标准的文档是他们所期望看到的最好的文档。

　　在做了很多工作之后，该委员会获得了成功。1997年10月，在Morristown（New Jersey，USA）会议上，技术成员的最终投票结果是43-0。在获知这个结果以后，我们进行了庆祝活动！在1998年，ISO成员国以空前的22-0的投票结果批准了这个标准。为了获取大家的一致同意，委员会做了大量的技术工作，也使用了一些外交策略：在那个时候，我喜欢说"政治问题无法解决；我们必须找到引发该问题的技术问题并解决他"。我无法想象仅仅通过投票，因为少数听从多数才简单"解决"的问题，同时，由于"政治上的讨价还价"的问题也危害了我们最好的技术判断--而这个问题（模板的分开编译）仍然在"恶化"，需要寻找一个更好的技术方案。

　　在最后投票之前的一年里，委员会的工作是：

　　1. 细节、细节和更多的细节。

　　2. STL

　　3. 模板的分开编译

　　第一个问题很明显：国际标准必须用大量的篇幅来关注细节信息；实际上，实现（implement）和已有标准的兼容性是标准的关键目标，同时还是实现之间的工具和应用程式能够迁移的基础。标准是个712页的文档（加上索引等内容），他是采用高度技术化的和正式的方式编写的，因此为了理解真正的含义需要很多的细节信息。像以前相同，我在新语言规范上附加了新版的"C 编程语言"，以提供更有帮助意义和面向用户的语言描述。

　　STL的出现

　　第二个问题，STL（"标准模板类库"，他是ISO C 标准类库的容器和算法框架）成为标准的一部分是个主要的创新，并且他成为了新的用以思考已出现的编程技术的出发点。STL基本上革命性地脱离了我们原来思考容器和容器使用问题的方式。在Simula早期，容器（例如列表）曾是困扰人的：假如，并且只有当某个对象已（显式或隐式地）衍生自那些包含编译器所需链接信息的特定的"Link"或"Object"类的时候，他才能被放到容器中。这种容器基本上是引用Link的容器。这暗示着基本的类型（例如int和double）不能直接地放入容器中，数组类型（他直接支持基本的类型）必定跟其他的容器不同。此外，假如我们希望把真正的简单类对象（例如complex和Point）放入容器中，那么他们在时间和空间上就无法达到理想效果。他同时还暗示着这种容器不是静态类型安全的。例如，Circle能够被加入列表中，但是当他被提取出来的时候，我们只知道他是个Object，需要使用一个转换（显式类型转换）来恢复其静态类型。

　　Simula容器和数组关于内建和用户定义类型（只有后来的一些能够放入容器）、关于容器和数组（只有数组能够保存基本的类型；数组不能保存用户定义类型，只能保存用户定义类型的指针）都有一些奇怪的条款。Smalltalk使用了相同的方法，也有相同的问题，后来的一些语言（例如Java和C#）也是这样的。由于他有明显的效用，而且很多设计者现在都熟悉他，所以很多C 类库也遵循这种模型。但是，我却发现他是无规律的和低效率的（在时间和空间上），使用他研发真正通用的类库是不能够接受的。这就是我在1985年没有为C 提供适当的标准类库（这个失误）的根本原因。

　　当我编写D&E的时候，我知道了一种容器和容器使用的新方法，他是由Alex Stepanov研发的。Alex当时在HP实验室工作，之前在Bell实验室工作了多年，在那儿他接近了Andrew Koenig，我也在那儿和他讨论过类库设计和模板机制。他鼓励我进一步研究某些模板机制的泛化和效率，但是很幸运的是，他却没有说服我让模板更类似Ada泛型。假如他成功了，他就无法设计和实现STL了！

　　在1993年末，Alex在泛型编程技术方面显示了他最近十年的长期研究的进展，这种技术是基于严格的数学基础的、目标是成为"最通用和最高效"的编程技术。他是个容器和算法的框架。他首先联系了Andrew，Andrew花几天时间研究这种技术之后，就把他展示给我了。我的第一反映是很迷惑。我发现STL的容器和容器使用方式是多余的，甚至于是丑陋的。和很多通晓面向对象编程的程式员相同，我认为自己知道容器的样子和STL代码的样子有怎样的不同。但是，在我建立工具列表（我认为这个列表对于容器来说是很重要的）的几年里，令我惊讶的是，我发现STL除了一个条件之外，符合其他任何的条件。那个缺少的条件是使用通用基类为任何的衍生类（例如任何的对象或容器）提供服务（例如永续性）。但是，我不认为这种服务对容器的概念有本质的意义。

　　他让我花了几周时间才感觉到STL比较"舒适"。在那以后，我担心把一个全新样式的类库介绍给C 群体已太晚了。让标准委员会在标准进行过程中这么迟的时候接受新的和革命性的东西的成功几率是很小的（的确是这样的）。即使出现最好的情况，标准也会被延迟一年--而C 群体急切需要该标准。同时，委员会本质上是个保守的团体，而STL是革命性的。

　　因此成功的机会是很渺茫的，但是我还是在他上面进行着辛勤的工作。毕竟，由于C 没有足够大的、足够好的标准库，我的感觉很糟糕。Andrew Koenig尽了最大的努力来鼓励我，并且Alex Stepanov用他知道的最好的东西来游说Andy和我。幸运的是，Alex不太了解在委员会中使某种东西成为主流的难度，因此他不太沮丧，并且继续研究技术方面，继续为Andrew和我讲授。我开始给其他人解释STL背后的想法。

　　1993年10月，在加利福尼亚的San Jose举行的标准委员会会议上，我们邀请了Alex进行晚间演讲。"他叫做C 编程的科学，他处理了规则类型的大多数原则--连接构造、赋值和等同。我还介绍了转发迭代子的原则。我没有提起任何容器的问题，只提到一个算法：查找"。这次演讲是活跃的下层社会的大胆创新，而其巨大的乐趣使委员会的态度从"现在让我们作些主要的事情"变成了"等等，让我们瞧一瞧"。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有