在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++提供适当的标准类库（这个失误）的根本原因。