STL笔记(2) STL之父访谈录

年3月，dr.dobb's journal特约记者, 著名技术书籍作家al stevens采访了stl创始人alexander stepanov. 这份访谈纪录是迄今为止对于stl发展历史的最完备介绍, 侯捷先生在他的stl有关文章里推荐大家阅读这篇文章. 因此我将该文全文翻译如下:

q: 您对于generic programming进行了长时间的研究, 请就此谈谈.
a: 我开始考虑有关gp的问题是在70年代末期, 当时我注意到有些算法并不依赖于数据结构的特定实现，而只是依赖于该结构的几个基本的语义属性. 于是我开始研究大量不同的算法，结果发现大部分算法可以用这种方法从特定实现中抽象出来, 而且效率无损. 对我来说,效率是至关重要的, 要是一种算法抽象在实例化会导致性能的下降, 那可不够棒.
   
    当时我认为这项研究的正确方向是创造一种编程语言. 我和我的两个朋友一起开始干起来.一个是现在的纽约州立大学教授deepak kapur, 另一个是伦塞里尔技术学院教授david musser.当时我们三个在通用电器公司研究中心工作. 我们开始设计一种叫tecton的语言. 该语言有一种我们称为"通用结构"的东西, 其实不过是一些形式类型和属性的集合体, 人们可以用它来描述算法. 例如一些数学方面的结构充许人们在其上定义一个代数操作, 精化之,扩充之, 做各种各样的事.

虽然有很多有趣的创意, 最终该项研究没有取得任何实用成果, 因为tecton语言是函数型语言. 我们信奉backus的理念，相信自己能把编程从von neumann风格中解放出来. 我们不想使用副效应, 这一点限制了我们的能力, 因为存在大量需要使用诸如"状态", "副效应"等观念的算法.

我在70年代末期在tecton上面所认识到了一个有趣的问题: 被广泛接受的adt观念有着根本性的缺陷. 人们通常认为adt的特点是只暴露对象行为特征, 而将实现隐藏起来. 一项操作的复杂度被认为是与实现相关的属性, 所以抽象的时候应予忽略. 我则认识到, 在考虑一个(抽象)操作时, 复杂度(或者至少是一般观念上的复杂度)必须被同时考虑在内. 这一点现在已经成了gp的核心理念之一.

年时, c++中还没有模板, 这玩意儿在通用编程中是个必需品年的计算机的最小模型. c当时并不是什么利器. 但是当计算机被用来处理各种问题时, 作为最小模型的c成了一种非常强大的语言, 在各个领域解决各种问题时都非常高效. 这就是c可移植性的奥秘, 年我到惠普实验室从事通用库开发工作. 但实际上好几年我都是在作磁盘驱动器. 很有趣但跟
    gp毫不相关. 92年我终于回到了gp领域, 实验室主任bill worley建立了一个算法研究项目, 由我
    负责. 那时候c++已经有模板了. 我发现bjarne的模板设计方案是非常天才的. 在bell lab时, 我参
    加过有关模班设计的几个早期的讨论, 跟bjarne吵得很凶, 我认为c++的模板设计应该尽可能向ada的
    通用方案看齐. 我想可能我吵得太凶了, 结果bjarne决定坚决拒绝我的建议. 我当时就认识到在c++
    中设置模板函数的必要性了, 那时候好多人都觉得最好只有模板类. 不过我觉得一个模板函数在使用
    之前必须先显式实例化, 跟ada似的. bjarne死活不听我的, 他把模板函数设计成可以用重载机制来
    隐式实例化. 后来这个特别的技术在我的工作中变得至关重要, 我发现它容许我做很多在ada中不可能
    的任务. 非常高兴bjarne当初没听我的.

q: 您是什么时候第一次构思stl的, 最初的目的是什么?
a: 92年那个项目建立时由8个人, 渐渐地人越来越少, 最后剩下俩, 我和李梦, 而且李小姐是这个领域的新手. 在她的专业研究中编译器是主要工作, 不过她接受了gp研究的想法, 并且坚信此项研究将带给软件开发一个大变化, 要知道那时候有这个信念的认可是寥寥无几. 没有她, 我可不敢想象我能搞定stl, 毕竟stl标着两个人的名字:stepanov和lee. 我们写了一个庞大的库, 庞大的代码量, 庞大的数据结构组件,函数对象, 适配器类, 等等. 可是虽然有很多代码, 却没有文档. 我们的工作被认为是一个验证性项目,其目的是搞清楚到底能不能在使算法尽可能通用化的前提下仍然具有很高的效率. 我们化了很多时间来比较, 结果发现, 我们算法不仅最通用, 而且要率与手写代码一样高效, 这种程序设计风格在性能上是不打折扣的! 这个库在不断成长, 但是很难说它是什么时候成为一个"项目"的. stl的诞生是好几件事情的机缘巧合才促成的.

q: 什么时候, 什么原因促使您决定建议使stl成为ansi/iso标准c++一部分的?
a: 1993年夏, andy koenig跑到斯坦福来讲c++课, 我把一些有关的材料给他看, 我想他当时确实是很兴奋.他安排我9月到圣何塞给c++标准委员会做一个演讲. 我演讲的题目是"c++程序设计的科学", 讲得很理论化, 要点是存在一些c++的基本元素所必须遵循的, 有关基本操作的原则. 我举了一些例子, 比如构造函数, 赋值操作, 相等操作. 作为一种语言,   c++没有什么限制. 你可以用operator==()来做乘法. 但是相等操作就应该是相等操作. 它要有自反性,   a == a; 它要有对称性, a == b 则 b == a; 它还要有传递性. 作为一个数学公理, 相等操作对于其他操作是基本的要素. 构造函数和相等操作之间的联系就有公理性的东西在里边. 你用拷贝构造函数生成了一个新对象, 那么这个对象和原来那个就应该是相等的. c++是没有做强行要求, 但是这是我们都必须遵守这个规则. 同样的, 赋值操作也必须产生相等的对象. 我展示了一些基本操作的"公理", 还讲了一点迭代子(iterator), 以及一些通用算法怎样利用迭代子来工作. 我觉得那是一个两小时的枯燥演讲, 但却非常受欢迎. 不过我那时并没有想把这个东西塞在标准里, 它毕竟是太过先进的编程技术, 大概还不适于出现在现实世界里, 恐怕那些做实际工作的人对它没什么兴趣.

我是在9月做这个演讲的, 直到次年(1994)月, 我都没往ansi标准上动过什么脑筋. 1月6日, 我收到andy koenig的一封信(他那时是标准文档项目编辑), 信中说如果我希望stl成为标准库的一部分, 可以在1月25日之前提交一份建议到委员会. 我的答复是:"andy, 你发疯了吗?", 他答复道:"不错, 是的我发疯了, 为什么咱们不疯一次试试看?"

当时我们有很多代码, 但是没有文档, 更没有正式的建议书. 李小姐和我每星期工作80小时, 终于在期限之前写出一份正式的建议书. 当是时也, 只有andy一个人知道可能会发生些什么. 他是唯一的支持者, 在那段日子里他确实提供了很多帮助. 我们把建议寄出去了, 然后就是等待. 在写建议的过程中我们做了很多事. 当你把一个东西写下来, 特别是想到你写的可能会成为标准, 你就会发现设计中的所有纰漏. 寄出标准后,我们不得不一段一段重写了库中间的代码, 以及几百个组件, 一直到3月份圣迭戈会议之前. 然后我们又重新修订了建议书, 因为在重新写代码的过程中, 我们又发现建议书中间的很多瑕疵.

q: 您能描述一下当时委员会里的争论吗? 建议一开始是被支持呢, 还是反对?
a: 我当时无法预料会发生些什么. 我做了一个报告, 反响很好. 但当时有许多反对意见. 主要的意见是:这是一份庞大的建议, 而且来得太晚, 前一次会议上已经做出决议, 不在接受任何大的建议. 而这个东西是有史以来最大的建议, 包括了一大堆新玩艺. 投票的结果很有趣, 压倒多数的意见认为应对建议进行再考虑, 并把投票推迟到下次会议, 就是后来众所周知的滑铁卢会议.

bjarne stroustrup成了stl的强有力支持者. 很多人都通过建议、更改和修订的方式给予了帮助。bjarne干脆跑到这来跟我们一起工作了一个礼拜。andy更是无时无刻的帮助我们。c++是一种复杂的语言，不是总能搞得清楚确切的含义的。差不多每天我都要问andy和bjarne c++能不能干这干那。我得把特殊的荣誉归于andy，是他提出把stl作为c++标准库的一部分；而bjarne也成了委员会中stl的主要鼓吹者。其他要感谢的人还有：mike vilot，标准库小组的负责人； rogue wave公司的nathan myers(rogue wave是boland c++builder中stl方案的提供商 —— 译者)，andersen咨询公司的larry podmolik。确实有好多人要致谢。

在圣迭戈提出的stl实际与当时的c++，我们被要求用新的ansi/iso c++语言特性重写stl，这些特性中有一些是尚未实现的。为了正确使用这些新的、未实现的c++特性，bjarne和andy花了无以计数的时间来帮助我们。

人们希望容器独立于内存模式，这有点过分，因为语言本身并没有包括内存模式。所以我们得要想出一些机制来抽象内存模式。在stl的早期版本里，假定容器的容积可以用size_t类型来表示，迭代子之间的距离可以用ptrdiff_t来表示。现在我们被告知，你为什么不抽象的定义这些类型？这个要求比较高，连语言本身都没有抽象定义这些类型，而且c/c++数组还不能被这些类型定义所限定。年2月发行的ansi/iso c++工作文件中的类库有何影响？
a: stl被放进了滑铁卢会议的工作文件里。stl文档被分解成若干部分，放在了文件的不同部分中。mike 
    vilot负责此事。我并没有过多地参与编辑工作，甚至也不是c++委员会的成员。不过每次有关stl的
    建议都由我来考虑。委员会考虑还是满周到的。

q: 委员会后来又做了一些有关模板机制的改动，哪些影响到了stl？
a: 在stl被接受之前，有两个变化影响到了我们修订stl。其一是模板类增加了包含模板函数的能力。stl广泛地使用了这个特性来允许你建立各种容纳容器的容器。一个单独的构造函数就能让你建立一个能容纳list或其他容器的vector。还有一个模板构造函数，从迭代子构造容器对象，你可以用一对迭代子当作参数传给它，这对迭代子之间的元素都会被用来构造新的容器类对象。另一个stl用到的新特性是把模板自身当作模板参数传给模板类。这项技术被用在刚刚提到的allocator中。

q: 那么stl影响了模板机制吗？
a: 在弗基山谷的会议中，bjarne建议给模板增加一个"局部特殊化"(partial specialization)的特性。这个特性可以让很多算法和类效率更高，但也会带来代码体积上的问题。我跟bjarne在这个建议上共同研究了一段时间，这个建议就是为了使stl更高效而提出的。我们来解释一下什么是"局部特殊化"。你现在有一个模板函数 swap( t&, t& )，用来交换两个参数。但是当t是某些特殊的类型参数时，你想做一些特殊的事情。例如对于swap( int&, int& )，你想用一种特别的操作来交换数据。这一点在没有局部特殊化机制的情况下是不可能的。有了局部特殊化机制，你可以声明一个模板函数如下：
   
        template <class T> void swap( vector<T >&, vector<T> & );

这种形式给vector容器类的swap操作提供了一种特别的办法。从性能的角度讲，这是非常重要的。如果你用通用的形式去交换vector，会使用三个赋值操作，vector被复制三次，时间复杂度是线性的。然而，如果我们有一个局部特殊化的swap版本专门用来交换两个vector，你可以得到一个时间复杂度为常数的，非常快的操作，只要移动vector头部的两个指针就ok。这能让vector上的sort算法运行得更快。没有局部特殊化，让某一种特殊的vector，例如vector<int>运行得更快的唯一办法是让程序员自己定一个特殊的swap函数，这行得通，但是加重了程序员的负担。在大部分情况下，局部特殊化机制能够让算法在某些通用类上表现得更高效。你有最通用的swap，不那么通用的swap，更不通用的swap，完全特殊的swap这么一系列重载的swap，然后你使用局部特殊化，编译器会自动找到最接近的那个swap。另一个例子copy。现在我们的copy就是通过迭代子一个一个地拷贝。使用模板特殊化可以定义一个模板函数：

template <class t> t** copy( t**, t**, t** );

这可以用memcpy高效地拷贝一系列指针来实现，因为是指针拷贝，我们可以不必担心构造对象和析构对象的开销。这个模板函数可以定义一次，然后供整个库使用，而且用户不必操心。我们使用局部特殊化处理了一些算法。这是个重要的改进，据我所知在弗基山谷会议上得到了好评，将来会成为标准的一部分。(后来的确成了标准的一部分 —— 译者）

q: 除了标准类库外，stl对那一类的应用程序来说最有用处？
a: 我希望stl能够引导大家学习一种新的编程风格：通用编程。我相信这种风格适用于任何种类的应用程序。这种风格就是：用最通用的方式来写算法和数据结构。这些结构所要求的语义特性应该能够被清楚地归类和分类，而这些归类分类的原则应该是任何对象都能满足的。理解和发展这种技术还要很长时间，stl不过是这个过程的起点。

我们最终会对通用的组件有一个标准的分类，这些组件具有精心定义的接口和复杂度。程序员们将不必在微观层次上编程。你再也不用去写一个二分查找算法。就是在现在，stl也已经提供了好几个通用的二分查找算法，凡是能用二分查找算法的场合，都可以使用这些算法。算法所要求的前提条件很少：你只要在代码里使用它。我希望所有的组件都能有这么一天。我们会有一个标准的分类，人们不用再重复这些工作。

这就是douglas mcilroy的梦想，他在1969年关于"构件工厂"的那篇著名文章中所提出来的东西。stl就是这种"构件工厂"的一个范例。当然，还需要有主流的力量介入这种技术的发展之中，光靠研究机构不行，工业界应该想程序员提供组件和工具，帮助他们找到所需的组件，把组件粘合到一起，然后确定复杂度是否达到预期。

q: stl没有实现一个持久化(persistent)对象容器模型。map和multimap似乎是比较好的候选者，它们可以把对象按索引存入持久对象数据库。您在此方向上做了什么工作吗，或者对这类实现有何评论？
a：很多人都注意到这个问题。stl没实现持久化是有理由的。stl在当时已经是能被接受的最巨大的库了。再大一点的话，我认为委员会肯定不会接受。当然持久化是确实是一些人提出的问题。在设计stl，特别是设计allocator时，bjarne认为这个封装了内存模式的组件可以用来封装持久性内存模式。bjarne的洞察秋毫非常的重要和有趣，好几个对象数据库公司正在盯着这项技术。1994年10月我参加了object database management group的一个会议，我做了一个关于演说。他们非常感兴趣，想让他们正在形成中的组件库的接口与stl一致，但不包括allocator在内。不过该集团的某些成员仔细分析了allocator是否能够被用来实现持久化。我希望与stl接口一致的组件对象持久化方案能在接下来的一年里出现。

q：set，multiset，map和multimap是用红黑树实现的，您试过用其他的结构，比如b*树来实现吗？
a：我不认为b*适用于内存中的数据结构，不过当然这件事还是应该去做的。应该对许多其他的数据结构，比如跳表(skip list)、伸展树(splay tree)、半平衡树(half-balanced tree)等，也实现stl容器的标准接口。应该做这样的研究工作，因为stl提供了一个很好的框架，可以用来比较这些结构的性能。结口是固定的，基本的复杂度是固定的，现在我们就可一个对各种数据结构进行很有意义的比较了。在数据结构领域里有很多人用各种各样的接口来实现不同的数据结构，我希望他们能用stl框架来把这些数据结构变成通用的。
    （译者注：上面所提到的各种数据结构我以为大多并非急需，而一个stl没有提供而又是真正重要的数据结构是哈希结构。后来在stepanov和matt austern等人的sgi*stl中增补了hashset，hashmap和hashtable三种容器，使得这个stl实现才比较完满。众所周知，红黑树的时间复杂度为o(logn), 而理想hash结构为o(1)。当然，如果实现了持久化，b+树也是必须的。）

q：有没有编译器厂商跟您一起工作来把stl集成到他们的产品中去？
a：是的，我接到了很多厂家的电话。borland公司的peter becker出的力特别大。他帮助我实现了对应borland编译器的所有内存模式的allocator组件。symantec打算为他们的macintosh编译器提供一个stl实现。edison设计集团也很有帮助。我们从大多数编译器厂商都得到了帮助。
    （译者注：以目前的stl版本来看，最出色的无疑是sgi*stl和ibm stl for as/390，所有windows下的的stl实现都不令人满意。根据测试数据，windows下最好的stl运行在piii 500mhz上的速度远远落后与在250mhz sgi工作站（irix操作系统）上运行的sgi*stl。以我个人经验，linux也是运行stl的极佳平台。而在windows的stl实现中，又以borland c++builder的rogue wave stl为最差，其效率甚至低于jit执行方式下的java2。位内存模式编译器的支持，不过当前的重点显然是在32位上线性内存模式(flat model)的操作系统和编译器上。您觉得这种面向内存模式的方案以后还会有效吗？
a：抛开intel的体系结构不谈，内存模式是一个对象，封装了有关指针的信息：这个指针的整型尺寸和距离类型是什么，相关的引用类型是什么，等等。如果我们想利用各种内存，比如持久性内存，共享内存等等，抽象化的工作就非常重要了。行代码里，其他的一切，容器、算法等等，都与机器无关（年夏天面世，重点是对stl实现技术的详解，跟他那本标准c库实现和标准c++库实现的书类似。他是这本书的第一作者。该书可以作为stl的参考手册。我希望跟bjarne合作另写一本书，在c++/stl背景下介绍语言与库的交互作用。

好多工作都等着要做。为了stl的成功，人们需要对这种编程技术进行更多的试验性研究，更多的文章和书籍应该对此提供帮助。要准备开设此类课程，写一些入门指南，开发一些工具帮助人们漫游stl库。stl是一个框架，应该有好的工具来帮助使用这个框架。
    （译者注：他说这番话时，并没有预计到在接下来的几年里会发生什么。由于internet的大爆炸和java、vb、delphi等语言的巨大成功，工业界的重心一下子从经典的软件工程领域转移到internet上。再加上标准c++直到98年才制订，完全符合要求的编译器直到现在都还没有出现，stl并没有立刻成为人们心中的关注焦点。他提到的那本书也迟迟不能问世，年的一本关于标准c库的书使他名满天下。他现在是c/c++ use's journal的主编，与microsoft保持着良好的，甚至是过分亲密的关系，visual c++中的stl和其他的一些内容就是出自他的那只生花妙笔。不过由于跟ms的关系已经影响到了他的中立形象，现在有不少人对他有意见。

至于stepanov想象中的那本与stroustrup的书，起码目前是没听说。其实这两位都是典型的编程圣手，跟ken thompson和dennis ritchie是一路的，懒得亲自写书，往往做个第二作者。如果作为第一作者，写出来的书肯定是学院味十足，跟标准文件似的，不适合一般程序员阅读。在计算机科学领域，编程圣手同时又是写作高手的人是凤毛麟角，最著名的可能是外星人d. e. knuth, c++领域里则首推前面提到的andrew koenig。可惜我们中国程序员无缘看到他的书。）

q：通用编程跟oop之间有什么关系？
a：一句话，通用编程是oop基本思想的自然延续。什么是oop的基本思想呢？把组件的实现和接口分开，并且让组件具有多态性。不过，两者还是有根本的不同。oop强调在程序构造中语言要素的语法。你必须得继承，使用类，使用对象，对象传递消息。gp不关心你继承或是不继承，它的开端是分析产品的分类，有些什么种类，他们的行为如何。就是说，两件东西相等意味着什么？怎样正确地定义相等操作？不单单是相等操作那么简单，你往深处分析就会发现"相等"这个一般观念意味着两个对象部分，或者至少基本部分是相等的，据此我们就可以有一个通用的相等操作。再说对象的种类。假设存在一个顺序序列和一组对于顺序序列的操作。那么这些操作的语义是什么？从复杂度权衡的角度看，我们应该向用户提供什么样的顺序序列？该种序列上存在那些操作？那种排序是我们需要的？只有对这些组件的概念型分类搞清楚了，我们才能提到实现的问题：使用模板、继承还是宏？使用什么语言和技术？gp的基本观点是把抽象的软件组件和它们的行为用标准的分类学分类，出发点就是要建造真实的、高效的和不取决于语言的算法和数据结构。当然最终的载体还是语言，没有语言没法编程。stl使用c++，你也可以用ada来实现，用其他的语言来实现也行，结果会有所不同，但基本的东西是一样的。到处都要用到二分查找和排序，而这就是人们正在做的。对于容器的语义，不同的语言会带来轻微的不同。但是基本的区别很清楚是gp所依存的语义，以及语义分解。例如，我们决定需要一个组件swap，然后指出这个组件在不同的语言中如果工作。显然重点是语义以及语义分类。而oop所强调的（我认为是过分强调的）是清楚的定义类之间的层次关系。oop告诉了你如何建立层次关系，却没有告诉你这些关系的实质。
    （这段不太好理解，有一些术语可能要过一段时间才会有合适的中文翻译——译者）

q：您对stl和gp的未来怎么看?
a：我刚才提到过，程序员们的梦想是拥有一个标准的组件仓库，其中的组件都具有良好的、易于理解的和标准的接口。为了达成这一点，gp需要有一门专门的科学来作为基础和支柱。stl在某种程度上开始了这项工作，它对于某些基本的组件进行了语义上的分类。我们要在这上面下更多的功夫，目标是要将软件工程从一种手工艺技术转化为工程学科。这需要一门对于基本概念的分类学，以及一些关于这些基本概念的定理，这些定理必须是容易理解和掌握的，每一个程序员即使不能很清楚的知道这些定理，也能正确地使用它。很多人根本不知道交换律，但只要上过学的人都知道2+5等于5+2。我希望所有的程序员都能学习一些基本的语义属性和基本操作：赋值意味着什么？相等意味着什么？怎样建立数据结构，等等。

当前，c++是gp的最佳载体。我试过其他的语言，最后还是c++最理想地达成了抽象和高效的统一。但是我觉得可能设计出一种语言，基于c和很多c++的卓越思想，而又更适合于gp。它没有c++的一些缺陷，特别是不会像c++一样庞大。stl处理的东西是概念，什么是迭代子，不是类，不是类型，是概念。说得更正式一些，这是bourbaki所说的结构类型（structure type），是逻辑学家所说的理念（theory），或是类型理论学派的人所说的种类（sort），这种东西在c++里没有语言层面上的对应物（原文是incarnation，直译为肉身——译者），但是可以有。你可以拥有一种语言，使用它你可以探讨概念，精化概念，最终用一种非常"程序化"（programmatic，直译为节目的，在这里是指符合程序员习惯的——译者）的手段把它们转化为类。当然确实有一些语言能处理种类（sorts），但是当你想排序（sort）时它们没什么用处。我们能够有一种语言，用它我们能定义叫做foward iterator（前向迭代子）的东西，在stl里这是个概念，没有c++对应物。然后我们可以从forword iterator中发展出bidirectional iterator（双向迭代子），再发展出random iterator。可能设计一种语言大为简化gp，我完全相信该语言足够高效，其机器模型与c/c++充分接近。我完全相信能够设计出一种语言，一方面尽可能地靠近机器层面以达成绝对的高效，另一方面能够处理非常抽象化的实体。我认为该语言的抽象性能够超过c++，同时又与底层的机器之间契合得天衣无缝。我认为gp会影响到语言的研究方向，我们会有适于gp的实用语言。从这些话中你应该能猜出我下一步的计划。