??翻譯者 : myan
出處: http://www.sgi.com/technology/stl??
1995年3月，dr.dobb's journal特約記者, 著名技術書籍作家al stevens采訪了stl創始人alexander stepanov. 這份訪談紀錄是迄今為止對于stl發展歷史的最完備介紹, 侯捷先生在他的stl有關文章里推薦大家閱讀這篇文章. 因此我將該文全文翻譯如下:
q: 您對于generic programming進行了長時間的研究, 請就此談談.
a: 我開始考慮有關gp的問題是在7o年代末期, 當時我注意到有些算法并不依賴于數據結構的特定實現，而只是依賴于該結構的幾個基本的語義屬性. 于是我開始研究大量不同的算法，結果發現大部分算法可以用這種方法從特定實現中抽象出來, 而且效率無損. 對我來說,效率是至關重要的, 要是一種算法抽象在實例化會導致性能的下降, 那可不夠棒.
??
?? 當時我認為這項研究的正確方向是創造一種編程語言. 我和我的兩個朋友一起開始干起來.一個是現在的紐約州立大學教授deepak kapur, 另一個是倫塞里爾技術學院教授david musser.當時我們三個在通用電器公司研究中心工作. 我們開始設計一種叫tecton的語言. 該語言有一種我們稱為"通用結構"的東西, 其實不過是一些形式類型和屬性的集合體, 人們可以用它來描述算法. 例如一些數學方面的結構充許人們在其上定義一個代數操作, 精化之,擴充之, 做各種各樣的事.
?? 雖然有很多有趣的創意, 最終該項研究沒有取得任何實用成果, 因為tecton語言是函數型語言. 我們信奉backus的理念，相信自己能把編程從von neumann風格中解放出來. 我們不想使用副效應, 這一點限制了我們的能力, 因為存在大量需要使用諸如"狀態", "副效應"等觀念的算法.??
?? 我在70年代末期在tecton上面所認識到了一個有趣的問題: 被廣泛接受的adt觀念有著根本性的缺陷. 人們通常認為adt的特點是只暴露對象行為特征, 而將實現隱藏起來. 一項操作的復雜度被認為是與實現相關的屬性, 所以抽象的時候應予忽略. 我則認識到, 在考慮一個(抽象)操作時, 復雜度(或者至少是一般觀念上的復雜度)必須被同時考慮在內. 這一點現在已經成了gp的核心理念之一.
?? 例如一個抽象的棧stack類型,??僅僅保證你push進去的東西可以隨后被pop出來是不夠的,同樣極端重要的是, 不管stack有多大, 你的push操作必須能在常數時間內完成. 如果我寫了一個stack, 每push一次就慢一點, 那誰都不會用這個爛玩藝.
?? 我們是要把實現和界面分開, 但不能完全忽略復雜度. 復雜度必須是, 而且也確實是橫陳于模塊的使用者與實現者之間的不成文契約. adt觀念的引入是為了允許軟件模塊相互可替換. 但除非另一個模塊的操作復雜度與這個模塊類似, 否則你肯定不愿意實現這種互換.如果我用另外一個模塊替換原來的模塊, 并提供完全相同的接口和行為, 但就是復雜度不同, 那么用戶肯定不高興. 就算我費盡口舌介紹那些抽象實現的優點, 他肯定還是不樂意用. 復雜度必須被認為是接口的一部分.
?? 1983年左右, 我轉往紐約布魯克林技術大學任教. 開始研究的是圖的算法, 主要的合作伙伴是現在ibm的aaron kershenbaum. 他在圖和網絡算法方面是個專家, 我使他相信高序(high order)的思想和gp能夠應用在圖的算法中. 他支持我與他合作開始把這些想法用于實際的網絡算法. 某些圖的算法太復雜了, 只進行過理論分析, 從來沒有實現過. 他企圖建立一個包含有高序的通用組件的工具箱, 這樣某些算法就可以實現了. 我決定使用lisp語言的一個變種scheme語言來建立這樣一個工具箱. 我們倆建立了一個巨大的庫, 展示了各種編程技術.網絡算法是首要目標. 不久當時還在通用電器的david musser加了進來, 開發了更多的組件,一個非常大的庫. 這個庫供大學里的本科生使用, 但從未商業化. 在這項工作中, 我了解到副效應是很重要的, 不利用副效應, 你根本沒法進行圖操作. 你不能每次修改一個端點(vertex)時都在圖上兜圈子. 所以, 當時得到的經驗是在實現通用算法時可以把高序技術和副效應結合起來. 副效應不總是壞的, 只有在被錯誤使用時才是.
?? 1985年夏, 我回到通用電器講授有關高序程序設計的課程. 我展示了在構件復雜算法時這項技術的應用. 有一個聽課的人叫陳邇, 當時是信息系統實驗室的主任. 他問我是否能用ada語言實現這些技術, 形成一個工業強度的庫, 并表示可以提供支持. 我是個窮助教, 所以盡管我當時對于ada一無所知, 我還是回答"好的". 我跟dave musser一起建立這個ada庫. 這是很重要的一個時期, 從象scheme那樣的動態類型語言(dynamically typed language)轉向ada這樣的強類型語言, 使我認識到了強類型的重要性. 誰都知道強類型有助于糾錯. 我則發現在ada的通用編程中, 強類型是獲取設計思想的有力工具. 它不僅是查錯工具, 而且是思想工具.這項工作給了我對于組件空間進行正交分解的觀念. 我認識到, 軟件組件各自屬于不同的類別.oop的狂熱支持者認為一切都是對象. 但我在ada通用庫的工作中認識到, 這是不對的. 二分查找就不是個對象, 它是個算法. 此外, 我還認識到, 通過將組件空間分解到幾個不同的方向上, 我們可以減少組件的數量, 更重要的是, 我們可以提供一個設計產品的概念框架.
?? 隨后, 我在貝爾實驗室c++組中得到一份工作, 專事庫研究. 他們問我能不能用c++做類似的事.我那時還不懂c++, 但當然, 我說我行. 可結果我不行, 因為1987年時, c++中還沒有模板, 這玩意兒在通用編程中是個必需品. 結果只好用繼承來獲取通用性, 那顯然不理想.直到現在c++繼承機制也不大用在通用編程中, 我們來說說為什么. 很多人想用繼承實現數據結構和容器類, 結果幾乎全部一敗涂地. c++的繼承機制及與之相關的編程風格有著戲劇性的局限. 用這種方式進行通用編程, 連等于判斷這類的小問題都解決不了. 如果你以x類作為基類, 設計了一個虛函數operater==, 接受一個x類對象, 并由x派生類y, 那么y的operator==是在拿y類對象與x類對象做比較. 以動物為例, 定義animal類, 派生giraffe(長頸鹿)類. 定義一個成員函數mate(), 實現與另一個哺乳動物的交配操作, 返回一個animal對象. 現在看看你的派生類giraffe,它當然也有一個mate()方法, 結果一個長頸鹿同一個動物交配, 返回一個動物對象. 這成何體統?當然, 對于c++程序員來說, 交配函數沒那么重要, 可是operator==就很重要了.
?? 對付這種問題, 你得使用模板. 用模板機制, 一切如愿.
?? 盡管沒有模板, 我還是搞出來一個巨大的算法庫, 后來成了unix system laboratory standard component library的一部分. 在bell lab, 我從象andy koenig, bjarne stroustrup(andrew koenig, 前iso c++標準化委員會主席; bjarne stroustrup, c++之父 -- 譯者)這類專家身上學到很多東西. 我認識到c/c++的重要, 它們的一些成功之處是不能被忽略的. 特別是我發現指針是個好東東. 我不是說空懸的指針, 或是指向棧的指針. 我是說指針這個一般觀念. 地址的觀念被廣泛使用著. 沒有指針我們就沒法描述并行算法.
?? 我們現在來探討一下為什么說c是一種偉大的語言. 通常人們認為c是編程利器并且獲得如此成功,是因為unix是用c寫的. 我不同意. 計算機的體系結構是長時間發展演變的結果, 不是哪一個聰明的人創造的. 事實上是廣大程序員在解決實際問題的過程中提出的要求推動了那些天才提出這些體系. 計算機經過多次進化, 現在只需要處理字節地址索引的內存, 線性地址空間和指針. 這個進化結果是對于人們要求解決問題的自然反映. dennis ritchie天才的作品c, 正反映了演化了30年的計算機的最小模型. c當時并不是什么利器. 但是當計算機被用來處理各種問題時, 作為最小模型的c成了一種非常強大的語言, 在各個領域解決各種問題時都非常高效. 這就是c可移植性的奧秘, c是所有計算機的最佳抽象模型, 而且這種抽象確確實實是建立在實際的計算機, 而不是假想的計算機上的. 人們可以比較容易的理解c背后的機器模型, 比理解ada和scheme語言背后的機器模型要容易的多. c的成功是因為c做了正確的事, 不是因為at&t的極力鼓吹和unix.
?? c++的成功是因為bjarne stroustrup以c為出發點來改進c, 引入更多的編程技術, 但始終保持在c所定義的機器模型框架之內, 而不是閉門造車地自己搞出一個新的機器模型來. c的機器模型非常簡單. 你擁有內存, 對象保存在那里面, 你又有指向連續內存空間的指針, 很好理解. c++保留了這個模型, 不過大大擴展了內存中對象的范疇, 畢竟c的數據類型太有限了, 它允許你建立新的類型結構, 但不允許你定義類型方法. 這限制了類型系統的能力. c++把c的機器模型擴展為真正類型系統.
?? 1988年我到惠普實驗室從事通用庫開發工作. 但實際上好幾年我都是在作磁盤驅動器. 很有趣但跟
?? 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++數組還不能被這些類型定義所限定。我們發明了一個機制稱作"allocator"，封裝了內存模式的信息。這個機制深刻地影響了庫中間的每一個組件。你可能疑惑：內存模式和算法或者容器類接口有什么關系？如果你使用size_t這樣的東西，你就無法使用 t* 對象，因為存在不同的指針類型(t*, t huge *, 等等)。這樣你就不能使用引用，因為內存模式不同的話，會產成不同的引用類型。這樣就會導致標準庫產生龐大的分支。
?? 另外一件重要的事情是我們原先的關聯類型數據結構被擴展了。這比較容易一些，但是最為標準的東西總是很困難的，因為我們做的東西人們要使用很多年。從容器的觀點看，stl做了十分清楚的二分法設計。所有的容器類被分成兩種：順序的和關聯的，就好像常規的內存和按內容尋址的內存一般。這些容器的語義十分清楚。
?? 當我到滑鐵盧以后，bjarne用了不少時間來安慰我不要太在意成敗與否，因為雖然看上去似乎不會成功，但是我們畢竟做到了最好。我們試過了，所以應該坦然面對。成功的期望很低。我們估計大部分的意見將是反對。但是事實上，確實有一些反對意見，但不占上風。滑鐵盧投票的結果讓人大跌眼鏡，80%贊成，20%反對。所有人都預期會有一場惡戰，一場大論戰。結果是確實有爭論，但投票是壓倒性的。
q: stl對于1994年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。visual c++中的stl是著名大師p. j. plauger的個人作品，性能較好，但其queue組件效率很差，慎用）
q：stl包括了對ms-dos的16位內存模式編譯器的支持，不過當前的重點顯然是在32位上線性內存模式(flat model)的操作系統和編譯器上。您覺得這種面向內存模式的方案以后還會有效嗎？
a：拋開intel的體系結構不談，內存模式是一個對象，封裝了有關指針的信息：這個指針的整型尺寸和距離類型是什么，相關的引用類型是什么，等等。如果我們想利用各種內存，比如持久性內存，共享內存等等，抽象化的工作就非常重要了。stl的一個很漂亮的特性是整個庫中唯一與機器類型相關的部分——代表真實指針，真實引用的組件——被封裝到大約16行代碼里，其他的一切，容器、算法等等，都與機器無關（真是牛啊！）。從移植的觀點看，所有及其相關的東西，象是地址記法，指針等，都被封裝到一個微小的，很好理解的機制里面。這樣一來，allocator對于stl而言就不是那么重要了，至少不像對于基本數據結構和算法的分解那么重要。
q：ansi/iso c標準委員會認為像內存模式這類問題是平臺相關的，沒有對此做出什么具體規定。c++委員會會不會采取不同的態度？為什么？
a：我認為stl在內存模式這一點上跟c++標準相比是超前的。但是在c和c++之間有著顯著的不同。c++有構造函數和new操作符來對付內存模式問題，而且它們是語言的一部分。現在看來似乎讓new操作符像stl容器使用allocater那樣來工作是很有意義的。不過現在對問題的重要性不像stl出現之前那么顯著了，因為在大多數場合，stl數據結構將讓new失業。大部分人不再需要分配一個數組，因為stl在做這類事情上更為高效。要知道我對效率的迷信是無以復加的，可我在我的代碼里從不使用new，匯編代碼表明其效率比使用new時更高。隨著stl的廣泛使用，new會逐漸淡出江湖。而且stl永遠都會記住回收內存，因為當一個容器，比如vector退出作用域時，它的析構函數被調用，會把容器里的所有東西都析構。你也不必再擔心內存泄漏了。stl可以戲劇性地降低對于垃圾收集機制的需求。使用stl容器，你可以為所欲為，不用關心內存的管理，自有stl構造函數和析構函數來對付。
q：c++標準庫子委員會正在制訂標準名空間（namespace）和異常處理機制。stl類會有名空間嗎，會拋出異
常嗎？
a：是的。該委員會的幾個成員正在考慮這件事，他們的工作非常卓越。
q：現在的stl跟最終作為標準的stl會有多大不同？委員會會不會干預某些變化，新的設計會不會被嚴格地控
制起來？
a：多數人的意見看起來是不希望對stl做任何重要的改變。
q：在成為標準之前，程序員們怎樣的一些stl經驗？
a：他們可以從butler.hpl.hp.com/stl當下stl頭文件，在borland和ibm或其他足夠強勁的的編譯器中使用它。學習這種編程技術的唯一途徑是編程，看看范例，試著用這種技術來編程。
q：您正在和p. j. plauger合作一本stl的書。那本書的重點是什么？什么時候面世？
a：計劃95年夏天面世，重點是對stl實現技術的詳解，跟他那本標準c庫實現和標準c++庫實現的書類似。他是
這本書的第一作者。該書可以作為stl的參考手冊。我希望跟bjarne合作另寫一本書，在c++/stl背景下介紹語言與庫的交互作用。
?? 好多工作都等著要做。為了stl的成功，人們需要對這種編程技術進行更多的試驗性研究，更多的文章和書籍應該對此提供幫助。要準備開設此類課程，寫一些入門指南，開發一些工具幫助人們漫游stl庫。stl是一個
框架，應該有好的工具來幫助使用這個框架。
?? （譯者注：他說這番話時，并沒有預計到在接下來的幾年里會發生什么。由于internet的大爆炸和java、vb、delphi等語言的巨大成功，工業界的重心一下子從經典的軟件工程領域轉移到internet上。再加上標準c++直到98年才制訂，完全符合要求的編譯器直到現在都還沒有出現，stl并沒有立刻成為人們心中的關注焦點。他提到的那本書也遲遲不能問世，直到前幾天（2001年元旦之后），這本眾人久已期盼的書終于問世，由p. j. plauger, alexander stepanov, meng lee, david musser四大高手聯手奉獻，prentice hall出版。不過該書主要關注的是stl的實現技術，不適用于普通程序員。
???? 另外就p. j. plauger做一個簡介：其人是標準c中stdio庫的早期實現者之一，91年的一本關于標準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的實用語言。從這些話中你應該能猜出我下一步的計劃。
mengyan
譯于2001年1月
posted on 2006-09-11 07:31
Jerry Cat 閱讀(152)
評論(0) 編輯 收藏 引用