C++ STL輕鬆導學

　　 

---

　　做爲C++標準不可缺乏的一部分，STL應該是滲透在C++程序的角角落落裏的。STL不是實驗室裏的寵兒，也不是程序員桌上的擺設，她的激動人心並不是曇花一現。本教程旨在傳播和普及STL的基礎知識，若能借此機會爲STL的推廣作些力所能及的事情，到也是件讓人愉快的事情。

---

1 初識STL：解答一些疑問

1.1 一個最關心的問題：什麼是STL

　　"什麼是STL？"，假如你對STL還知之甚少，那麼我想，你必定很想知道這個問題的答案，坦率地講，要期望用短短數言將這個問題闡述清楚，也決非易事。所以，若是你在看完本節以後仍是以爲似懂非懂，大可沒必要着急，在閱讀了後續內容以後，相信你對STL的認識，將會越發清晰、準確和完整。不過，上述這番話聽起來是否有點像是在爲本身糟糕的表達能力開脫罪責呢？

　　不知道你是否有過這樣的經歷。在你準備着手完成數據結構老師所佈置的家庭做業時，或者在你爲你所負責的某個軟件項目中添加一項新功能時，你發現須要用到一個鏈表(List)或者是映射表（Map）之類的東西，可是手頭並無現成的代碼。因而在你開始正式考慮程序功能以前，手工實現List或者Map是不可避免的。因而……，最終你順利完成了任務。或許此時，做爲一個具備較高素養的程序員的你還不願罷休（或者是一個喜歡偷懶的優等生:），由於你會想到，若是之後還遇到這樣的狀況怎麼辦？沒有必要再作一遍一樣的事情吧！

　　若是說上述這種情形天天都在發生，或許有點誇張。可是，若是說整個軟件領域裏，數十年來確實都在爲了一個目標而奮鬥--可複用性（reusability），這看起來彷佛並不誇張。從最先的面向過程的函數庫，到面向對象的程序設計思想，到各類組件技術（如：COM、EJB），到設計模式（design pattern）等等。而STL也在作着相似的事情，同時在它背後蘊涵着一種新的程序設計思想--泛型化設計（generic programming）。

　　繼續上面提到的那個例子，假如你把List或者map無缺的保留了下來，正在暗自得意。且慢，若是下一回的List裏放的不是浮點數而是整數呢？若是你所實現的Map在效率上老是令你不太滿意而且有時還會出些bug呢？你該如何面對這些問題？使用STL是一個不錯的選擇，確實如此，STL能夠漂亮地解決上面提到的這些問題，儘管你還能夠尋求其餘方法。

說了半天，到底STL是什麼東西呢？

　　STL（Standard Template Library），即標準模板庫，是一個具備工業強度的，高效的C++程序庫。它被容納於C++標準程序庫（C++ Standard Library）中，是ANSI/ISO C++標準中最新的也是極具革命性的一部分。該庫包含了諸多在計算機科學領域裏所經常使用的基本數據結構和基本算法。爲廣大C++程序員們提供了一個可擴展的應用框架，高度體現了軟件的可複用性。這種現象有些相似於Microsoft Visual C++中的MFC（Microsoft Foundation Class Library），或者是Borland C++ Builder中的VCL(Visual Component Library)，對於此兩者，你們必定不會陌生吧。

　　從邏輯層次來看，在STL中體現了泛型化程序設計的思想（generic programming），引入了諸多新的名詞，好比像需求（requirements），概念（concept），模型（model），容器（container），算法（algorithmn），迭代子（iterator）等。與OOP（object-oriented programming）中的多態（polymorphism）同樣，泛型也是一種軟件的複用技術。

　　從實現層次看，整個STL是以一種類型參數化（type parameterized）的方式實現的，這種方式基於一個在早先C++標準中沒有出現的語言特性--模板（template）。若是查閱任何一個版本的STL源代碼，你就會發現，模板做爲構成整個STL的基石是一件千真萬確的事情。除此以外，還有許多C++的新特性爲STL的實現提供了方便。

　　不知你對這裏一會兒冒出這麼多術語作何感想，但願不會另你不愉快。假如你對它們之中的大多數不甚瞭解，敬請放心，在後續內容中將會對這些名詞逐一論述。正如開頭所提到的。

　　有趣的是，對於STL還有另一種解釋--STepanov & Lee，前者是指Alexander Stepanov，STL的創始人；然後者是Meng Lee，她也是使STL得以推行的功臣，第一個STL成品就是他們合做完成的。這一提法源自1995年3月，Dr.Dobb's Journal特約記者, 著名技術書籍做家Al Stevens對Alexander Stepanov的一篇專訪。

1.2 追根溯源：STL的歷史

　　在結識新朋友的時候，大多數人老是忍不住想了解對方的過去。本節將帶您簡單回顧一下STL的過去。

　　被譽爲STL之父的Alexander Stepanov，出生於蘇聯莫斯科，早在20世紀70年代後半期，他便已經開始考慮，在保證效率的前提下，將算法從諸多具體應用之中抽象出來的可能性，這即是後來泛型化思想的雛形。爲了驗證本身的思想，他和紐約州立大學教授Deepak Kapur，倫塞里爾技術學院教授David Musser共同開發了一種叫作Tecton的語言。儘管此次嘗試最終沒有取得實用性的成果，但卻給了Stepanov很大的啓示。

　　在隨後的幾年中，他又和David Musser等人前後用Schema語言（一種Lisp語言的變種）和Ada語言創建了一些大型程序庫。這其間，Alexander Stepanov開始意識到，在當時的面向對象程序設計思想中所存在的一些問題，好比抽象數據類型概念所存在的缺陷。Stepanov但願經過對軟件領域中各組成部分的分類，逐漸造成一種軟件設計的概念性框架。

　　1987年左右，在貝爾實驗室工做的Alexander Stepanov開始首次採用C++語言進行泛型軟件庫的研究。但遺憾的是，當時的C++語言尚未引入模板（template）的語法，如今咱們能夠清楚的看到，模板概念之於STL實現，是何等重要。是時使然，採用繼承機制是別無選擇的。儘管如此，Stepanov仍是開發出了一個龐大的算法庫。與此同時，在與Andrew Koenig（前ISO C++標準化委員會主席）和Bjarne Stroustrup（C++語言的創始人）等頂級大師們的共事過程當中，Stepanov開始注意到C/C++語言在實現其泛型思想方面所具備的潛在優點。就拿C/C++中的指針而言，它的靈活與高效運用，使後來的STL在實現泛型化的同時更是保持了高效率。另外，在STL中佔據極其重要地位的迭代子概念即是源自於C/C++中原生指針（ native pointer）的抽象。

　　1988年，Alexander Stepanov開始進入惠普的Palo Alto實驗室工做，在隨後的4年中，他從事的是有關磁盤驅動器方面的工做。直到1992年，因爲參加並主持了實驗室主任Bill Worley所創建的一個有關算法的研究項目，才使他從新回到了泛型化算法的研究工做上來。項目自創建以後，參與者從最初的8人逐漸減小，最後只剩下兩我的--Stepanove本人和Meng Lee。通過長時間的努力，最終，信念與汗水所換來的是一個包含有大量數據結構和算法部件的龐大運行庫。這即是如今的STL的雛形（同時也是STL的一個實現版本--HP STL）。

　　1993年，當時在貝爾實驗室的Andrew Koenig看到了Stepanove的研究成果，非常興奮。在他的鼓勵與幫助下，Stepanove因而年9月的聖何塞爲ANSI/ISO C++標準委員會作了一個相關演講（題爲"The Science of C++ Programming"），向委員們講述了其觀念。而後又於次年3月，在聖迭戈會議上，向委員會提交了一份建議書，以期使STL成爲C++標準庫的一部分。儘管這一建議十分龐大，以致於下降了被經過的可能性，但因爲其所包含的新思想，投票結果以壓倒多數的意見認爲推遲對該建議的決定。

　　隨後，在衆人的幫助之下，包括Bjarne Stroustrup在內，Stepanove又對STL進行了改進。同時加入了一個封裝內存模式信息的抽象模塊，也就是如今STL中的allocator，它使STL的大部分實現均可以獨立於具體的內存模式，從而獨立於具體平臺。在同年夏季的滑鐵盧會議上，委員們以80%同意，20%反對，最終經過了提案，決定將STL正式歸入C++標準化進程之中，隨後STL便被放進了會議的工做文件中。自此，STL終於成爲了C++家族中的重要一員。

　　此後，隨着C++標準的不斷改進，STL也在不斷地做着相應的演化。直至1998年，ANSI/ISO C++標準正式定案，STL始終是C++標準中不可或缺的一大部件。

1.3 千絲萬縷的聯繫

　　在你瞭解了STL的過去以後，一些名詞開始不斷在你的大腦中浮現，STL、C++、C++標準函數庫、泛型程序設計、面向對象程序設計……，這些概念意味着什麼？他們之間的關係又是什麼？若是你想了解某些細節，這裏也許有你但願獲得的答案。

1.3.1 STL和C++

　　沒有C++語言就沒有STL，這麼說絕不爲過。通常而言，STL做爲一個泛型化的數據結構和算法庫，並不牽涉具體語言（固然，在C++裏，它被稱爲STL）。也就是說，若是條件容許，用其餘語言也能夠實現之。這裏所說的條件，主要是指相似於"模板"這樣的語法機制。若是你沒有略過前一節內容的話，應該能夠看到，Alexander Stepanov在選擇C++語言做爲實現工具以前，早以採用過多種程序設計語言。可是，爲何最終仍是C++幸運的承擔了這個歷史性任務呢？緣由不只在於前述那個條件，還在於C++在某些方面所表現出來的優越特性，好比：高效而靈活的指針。可是若是把C++做爲一種OOP（Object-Oriented Programming，面向對象程序設計）語言來看待的話（事實上咱們通常都是這麼認爲的，不是嗎？），其功能強大的繼承機制卻沒有給STL的實現幫上多大的忙。在STL的源代碼裏，並無太多太複雜的繼承關係。繼承的思想，甚而面向對象的思想，還不足以實現相似STL這樣的泛型庫。C++只有在引入了"模板"以後，才直接致使了STL的誕生。這也正是爲何，用其餘比C++更純的面嚮對象語言沒法實現泛型思想的一個重要緣由。固然，事情老是在變化之中，像Java在這方面，就是一個很好的例子，jdk1.4中已經加入了泛型的特性。

　　此外，STL對於C++的發展，尤爲是模板機制，也起到了促進做用。好比：模板函數的偏特化（template function partial specialization），它被用於在特定應用場合，爲通常模板函數提供一系列特殊化版本。這一特性是繼STL被ANSI/ISO C++標準委員會經過以後，在Bjarne和Stepanov共同商討之下並由Bjarne向委員會提出建議的，最終該項建議被經過。這使得STL中的一些算法在處理特殊情形時能夠選擇非通常化的方式，從而保證了執行的效率。

1.3.2 STL和C++標準函數庫

　　STL是最新的C++標準函數庫中的一個子集，這個龐大的子集佔據了整個庫的大約80%的份量。而做爲在實現STL過程當中扮演關鍵角色的模板則充斥了幾乎整個C++標準函數庫。在這裏，咱們有必要看一看C++標準函數庫裏包含了哪些內容，其中又有哪些是屬於標準模板庫（即STL）的。

　　C++標準函數庫爲C++程序員們提供了一個可擴展的基礎性框架。咱們從中能夠得到極大的便利，同時也能夠經過繼承現有類，本身編制符合接口規範的容器、算法、迭代子等方式對之進行擴展。它大體包含了以下幾個組件：

　　C標準函數庫，基本保持了與原有C語言程序庫的良好兼容，儘管有些微變化。人們總會忍不住留戀過去的美好歲月，若是你曾經是一個C程序員，對這一點必定體會頗深。或許有一點會讓你以爲奇怪，那就是在C++標準庫中存在兩套C的函數庫，一套是帶有.h擴展名的（好比<stdio.h>），而另外一套則沒有（好比<cstdio>）。它們確實沒有太大的不一樣。

　　語言支持（language support）部分，包含了一些標準類型的定義以及其餘特性的定義，這些內容，被用於標準庫的其餘地方或是具體的應用程序中。

　　診斷（diagnostics）部分，提供了用於程序診斷和報錯的功能，包含了異常處理（exception handling），斷言（assertions），錯誤代碼（error number codes）三種方式。

　　通用工具（general utilities）部分，這部份內容爲C++標準庫的其餘部分提供支持，固然你也能夠在本身的程序中調用相應功能。好比：動態內存管理工具，日期/時間處理工具。記住，這裏的內容也已經被泛化了（即採用了模板機制）。

　　字符串（string）部分，用來表明和處理文本。它提供了足夠豐富的功能。事實上，文本是一個string對象，它能夠被看做是一個字符序列，字符類型多是char，或者wchar_t等等。string能夠被轉換成char*類型，這樣即可以和之前所寫的C/C++代碼和平共處了。由於那時侯除了char*，沒有別的。

　　國際化（internationalization）部分，做爲OOP特性之一的封裝機制在這裏扮演着消除文化和地域差別的角色，採用locale和facet能夠爲程序提供衆多國際化支持，包括對各類字符集的支持，日期和時間的表示，數值和貨幣的處理等等。畢竟，在中國和在美國，人們表示日期的習慣是不一樣的。

　　容器（containers）部分，STL的一個重要組成部分，涵蓋了許多數據結構，好比前面曾經提到的鏈表，還有：vector（相似於大小可動態增長的數組）、queue（隊列）、stack（堆棧）……。string也能夠看做是一個容器，適用於容器的方法一樣也適用於string。如今你能夠輕鬆的完成數據結構課程的家庭做業了。

　　算法（algorithms）部分，STL的一個重要組成部分，包含了大約70個通用算法，用於操控各類容器，同時也能夠操控內建數組。好比：find用於在容器中查找等於某個特定值的元素，for_each用於將某個函數應用到容器中的各個元素上，sort用於對容器中的元素排序。全部這些操做都是在保證執行效率的前提下進行的，因此，若是在你使用了這些算法以後程序變得效率底下，首先必定不要懷疑這些算法自己，仔細檢查一下程序的其餘地方。

　　迭代器（iterators）部分，STL的一個重要組成部分，若是沒有迭代器的撮合，容器和算法便沒法結合的如此完美。事實上，每一個容器都有本身的迭代器，只有容器本身才知道如何訪問本身的元素。它有點像指針，算法經過迭代器來定位和操控容器中的元素。

　　數值（numerics）部分，包含了一些數學運算功能，提供了複數運算的支持。

　　輸入/輸出（input/output）部分，就是通過模板化了的原有標準庫中的iostream部分，它提供了對C++程序輸入輸出的基本支持。在功能上保持了與原有iostream的兼容，而且增長了異常處理的機制，並支持國際化（internationalization）。

　　整體上，在C++標準函數庫中，STL主要包含了容器、算法、迭代器。string也能夠算作是STL的一部分。

 

圖1：STL和C++標準函數庫

1.3.3 STL和GP，GP和OOP

　　正如前面所提到的，在STL的背後蘊含着泛型化程序設計（GP）的思想，在這種思想裏，大部分基本算法被抽象，被泛化，獨立於與之對應的數據結構，用於以相同或相近的方式處理各類不一樣情形。這一思想和麪向對象的程序設計思想（OOP）不盡相同，由於，在OOP中更注重的是對數據的抽象，即所謂抽象數據類型（Abstract Data Type），而算法則一般被附屬於數據類型之中。幾乎全部的事情均可以被看做類或者對象（即類的實例），一般，咱們所看到的算法被做爲成員函數（member function）包含在類（class）中，類和類則構成了錯綜複雜的繼承體系。

　　儘管在象C++這樣的程序設計語言中，你還能夠用全局函數來表示算法，可是在相似於Java這樣的純面向對象的語言中，全局函數已經被"勒令禁止"了。所以，用Java來模擬GP思想是頗爲困難的。若是你對前述的STL歷史還有印象的話，應該記得Alexander Stepanove也曾用基於OOP的語言嘗試過實現GP思想，可是效果並很差，包括沒有引入模板以前的C++語言。站在巨人的肩膀上，咱們能夠得出這樣的結論，在OOP中所體現的思想與GP的思想確實是相異的。C++並非一種純面向對象的程序設計語言，它的絕妙之處，就在於既知足了OOP，又成全了GP。對於後者，模板立下了汗馬功勞。另外，須要指出的是，儘管GP和OOP有諸多不一樣，但這種不一樣還不至於到"水火不容"的地步。而且，在實際運用的時候，二者的結合使用每每能夠使問題的解決更爲有效。做爲GP思想實例的STL自己即是一個很好的範例，若是沒有繼承，不知道STL會是什麼樣子，彷佛沒有人作過這樣的試驗。

1.4 STL的不一樣實現版本

　　相信你對STL的感性認識應該有所提升了，是該作一些實際的工做了，那麼咱們首先來了解一下STL的不一樣實現版本。ANSI/ISO C++文件中的STL是一個僅被描述在紙上的標準，對於諸多C++編譯器而言，須要有各自實際的STL，它們或多或少的實現了標準中所描述的內容，這樣纔可以爲咱們所用。之因此有不一樣的實現版本，則存在諸多緣由，有歷史的緣由，也有各自編譯器生產廠商的緣由。如下是幾個常見的STL實現版本。　　

1.4.1 HP STL

　　HP STL是全部其它STL實現版本的根源。它是STL之父Alexander Stepanov在惠普的Palo Alto實驗室工做時，和Meng Lee共同完成的，是第一個STL的實現版本（參見1.2節）。這個STL是開放源碼的，因此它容許任何人無償使用、複製、修改、發佈和銷售該軟件和相關文檔，前提是必須在全部相關文件中加入HP STL的版本信息和受權信息。如今已經不多直接使用這個版本的STL了。

1.4.2 P.J. Plauger STL

　　　　P. J. Plauger STL屬於我的做品，由P. J. Plauger本人實現，是HP STL的一個繼承版本，所以在其全部頭文件中都含有HP STL的相關聲明，同時還有P. J. Plauger本人的版權聲明。P. J. Plauger是標準C中stdio庫的早期實現者，如今是C/C++ User's Journal的主編，與Microsoft保持着良好的關係。P. J. Plauger STL即是被用於Microsoft的Visual C++中的。在Windows平臺下的同類版本中，其性能不錯，可是queue組件（隊列，一種容器）的效率不理想，同時因爲Visual C++對C++語言標準的支持不是很好（至少直到VC6.0爲止，仍是如此），所以必定程度上影響了P. J. Plauger STL的性能。此外，該版本的源代碼可讀性較差，你能夠在VC的Include子目錄下找到全部源文件（好比：C:\Program Files\Microsoft Visual Studio\VC98\Include）。由於不是開放源碼的（open source），因此這些源代碼是不能修改和銷售的，目前P.J. Plauger STL由Dinkumware公司提供相關服務，詳情請見http://www.dinkumware.com。據稱Visual Studio.NET中的Visual C++.NET（即VC7.0），對C++標準的支持有所提升，而且多了以哈希表（hash table）爲基礎而實現的map容器，multimap容器和set容器。

1.4.3 Rouge Wave STL

Rouge Wave STL是由Rouge Wave公司實現的，也是HP STL的一個繼承版本，除了HP STL的相關聲明以外，還有Rouge Wave公司的版權聲明。同時，它也不是開放源碼的，所以沒法修改和銷售。該版本被Borland C++ Builder所採用，你能夠在C++ Builder的Include子目錄下找到全部頭文件（好比：C:\Program Files\Borland\Cbuilder5\Include）。儘管Rouge Wave STL的性能不是很好，但因爲C++ Builder對C++語言標準的支持還算不錯，使其表如今必定程度上得以改善。此外，其源代碼的可讀性較好。能夠從以下網站獲得更詳細的狀況介紹：http://www.rougewave.com。遺憾的是該版本已有一段時間沒有更新且不徹底符合標準。所以在Borland C++ Builder 6.0中，它的地位被另外一個STL的實現版本--STLport（見後）取代了。可是考慮到與之前版本的兼容，C++ Builder 6.0仍是保留了Rouge Wave STL，只是若是你想查看它的源代碼的話，須要在別的目錄中才能找到（好比：C:\Program Files\Borland\Cbuilder6\Include\oldstl）。

1.4.4 STLport

　　STLport最初源於俄國人Boris Fomitchev的一個開發項目，主要用於將SGI STL的基本代碼移植到其餘諸如C++Builder或者是Visual C++這樣的主流編譯器上。由於SGI STL屬於開放源碼，因此STLport纔有權這樣作。目前STLport的最新版本是4.5。能夠從以下網站獲得更詳細的狀況介紹：http://www.stlport.org，能夠免費下載其源代碼。STLport已經被C/C++技術委員會接受成爲工業標準，且在許多平臺上都支持。根據測試STLport的效率比VC中的STL要快。比Rouge Wave STL更符合標準，也更容易移植。Borland C++ Builder已經在其6.0版中加入了對STLport的支持，它使用的STLport就是4.5版的，C++ Builder 6.0同時還提供了STLport的使用說明。你能夠在C++ Builder的Include\Stlport子目錄下找到全部頭文件（好比：C:\Program Files\Borland\Cbuilder6\Include\Stlport）。

1.4.5 SGI STL

　　　　SGI STL是由Silicon Graphics Computer System, Inc公司實現的，其設計者和編寫者包括Alexander Stepanov和Matt Austern，一樣它也是HP STL的一個繼承版本。它屬於開放源碼，所以你能夠修改和銷售它。SGI STL被GCC（linux下的C++編譯器）所採用，你能夠在GCC的Include子目錄下找到全部頭文件（好比：C:\cygnus\cygwin-b20\include\g++\include）。因爲GCC對C++語言標準的支持很好，SGI STL在linux平臺上的性能至關出色。此外，其源代碼的可讀性也很好。能夠從以下網站獲得更詳細的狀況介紹：http://www.sgi.com，能夠免費下載其源代碼。目前的最新版本是3.3。

 

圖2：STL家族的譜系

 

2 牛刀小試：且看一個簡單例程

2.1 引子

　　若是你是一個純粹的實用主義者，也許一開始就能夠從這裏開始看起，由於此處提供了一個示例程序，它能夠帶給你有關使用STL的最直接的感覺。是的，與其紙上談兵，不如單刀直入，實際操做一番。可是，須要提醒的是，假如你在興致昂然地細細品味本章內容的時候，可以同時結合前面章節做爲佐餐，那將是再好不過的。你會發現，前面所提到的有關STL的那些優勢，在此處獲得了確切的應證。本章的後半部分，將爲你演示在一些主流C++編譯器上，運行上述示例程序的具體操做方法，和須要注意的事項。

2.2 例程實做

　　很是遺憾，我不得不捨棄"Hello World"這個經典的範例，儘管它不僅一次的被各類介紹計算機語言的教科書所引用，幾乎成爲了一個默認的「標準」。其緣由在於它太過簡單了，以致於不具有表明性，沒法展示STL的巨大魅力。我選用了一個稍稍複雜一點的例子，它的大體功能是：從標準輸入設備（通常是鍵盤）讀入一些整型數據，而後對它們進行排序，最終將結果輸出到標準輸出設備（通常是顯示器屏幕）。這是一種典型的處理方式，程序自己具有了一個系統所應該具備的幾乎全部的基本特徵：輸入 + 處理 + 輸出。你將會看到三個不一樣版本的程序。第一個是沒有使用STL的普通C++程序，你將會看到完成這樣看似簡單的事情，須要花多大的力氣，並且還未必沒有一點問題（真是吃力不討好）。第二個程序的主體部分使用了STL特性，此時在第一個程序中所遇到的問題就基本能夠解決了。同時，你會發現採用了STL以後，程序變得簡潔明快，清晰易讀。第三個程序則將STL的功能發揮到了及至，你能夠看到程序裏幾乎每一行代碼都是和STL相關的。這樣的機會並不老是隨處可見的，它展示了STL中的幾乎全部的基本組成部分，儘管這看起來彷佛有點過度了。

　　有幾點是須要說明的：

　　這個例程的目的，在於向你演示如何在C++程序中使用STL，同時但願經過實踐，證實STL所帶給你的確確實實的好處。程序中用到的一些STL基本組件，好比：vector（一種容器）、sort（一種排序算法），你只須要有一個大體的概念就能夠了，這並不影響閱讀代碼和理解程序的含義。

　　不少人對GUI（圖形用戶界面）的運行方式很感興趣，這也難怪，漂亮的界面老是會使人賞心悅目的。可是很惋惜，在這裏沒有加入這些功能。這很容易解釋，對於所提供的這個簡單示例程序而言，加入GUI特性，是有點本末倒置的。這將會使程序的代碼量驟然間急劇膨脹，而真正能夠說明問題的核心部分確被淹沒在諸多可有可無的代碼中間（你須要花去極大的精力來處理鍵盤或者鼠標的消息響應這些繁瑣而又較爲規範的事情）。即便你有像Borland C++ Builder這樣的基於IDE（集成化開發環境）的工具，界面的處理變得較爲簡單了（框架代碼是自動生成的）。請注意，咱們這裏所談及的是屬於C++標準的一部分（STL的第一個字母說明了這一點），它不涉及具體的某個開發工具，它是幾乎在任何C++編譯器上都能編譯經過的代碼。畢竟，在Microsoft Visual C++和Borland C++ Builder裏，有關GUI的處理代碼是不同的。若是你想了解這些GUI的細節，這裏恐怕沒有你但願獲得的答案，你能夠尋找其它相關書籍。

2.2.1 初版：史前時代--轉木取火

在STL尚未降生的"黑暗時代"，C++程序員要完成前面所提到的那些功能，須要作不少事情（不過這比起C程序來，彷佛好一點），程序大體是以下這個樣子的：

 

 1 // name:example2_1.cpp
 2 // alias:Rubish
 3 
 4 #include <stdlib.h>
 5 #include <iostream.h>
 6 
 7 int compare(const void *arg1, const void *arg2);
 8 
 9 void main(void)
10 {
11     const int max_size = 10;        // 數組容許元素的最大個數
12     int num[max_size];            // 整型數組
13 
14     // 從標準輸入設備讀入整數，同時累計輸入個數，
15     // 直到輸入的是非整型數據爲止
16     int n;
17     for (n = 0; cin >> num[n]; n ++);
18 
19     // C標準庫中的快速排序（quick-sort）函數
20     qsort(num, n, sizeof(int), compare);
21 
22     // 將排序結果輸出到標準輸出設備
23     for (int i = 0; i < n; i ++)
24         cout << num[i] << "\n";
25 }
26 
27 // 比較兩個數的大小，
28 // 若是*(int *)arg1比*(int *)arg2小，則返回-1
29 // 若是*(int *)arg1比*(int *)arg2大，則返回1
30 // 若是*(int *)arg1等於*(int *)arg2，則返回0
31 int compare(const void *arg1, const void *arg2)
32 {
33     return    (*(int *)arg1 < *(int *)arg2) ? -1 :
34             (*(int *)arg1 > *(int *)arg2) ? 1 : 0;
35 }

 

　　這是一個和STL沒有絲毫關係的傳統風格的C++程序。由於程序的註釋已經很詳盡了，因此不須要我再作更多的解釋。總的說來，這個程序看起來並不十分複雜（原本就沒有太多功能）。只是，那個compare函數，看起來有點費勁。指向它的函數指針被做爲最後一個實參傳入qsort函數，qsort是C程序庫stdlib.h中的一個函數。如下是qsort的函數原型：

1 void qsort(void *base, size_t num, size_t width, int (__cdecl *compare )(const void *elem1, const void *elem2 ) );

 

　　看起來有點使人做嘔，尤爲是最後一個參數。大概的意思是，第一個參數指明瞭要排序的數組（好比：程序中的num），第二個參數給出了數組的大小（qsort沒有足夠的智力預知你傳給它的數組的實際大小），第三個參數給出了數組中每一個元素以字節爲單位的大小。最後那個長長的傢伙，給出了排序時比較元素的方式（仍是由於qsort的智商問題）。

如下是某次運行的結果：

 輸入：0 9 2 1 5
 輸出：0 1 2 5 9      

 

　　有一個問題，這個程序並不像看起來那麼健壯（Robust）。若是咱們輸入的數字個數超過max_size所規定的上限，就會出現數組越界問題。若是你在Visual C++的IDE環境下以控制檯方式運行這個程序時，會彈出非法內存訪問的錯誤對話框。

這個問題很嚴重，嚴重到足以使你開始從新審視這個程序的代碼。爲了彌補程序中的這一缺陷。咱們不得不考慮採用以下三種方案中的一種：

• 採用大容量的靜態數組分配。
• 限定輸入的數據個數。
• 採用動態內存分配。

　　第一種方案比較簡單，你所作的只是將max_size改大一點，好比：1000或者10000。可是，嚴格講這並不能最終解決問題，隱患仍然存在。假若有人足夠耐心，仍是能夠使你的這個通過糾正後的程序崩潰的。此外，分配一個大數組，一般是在浪費空間，由於大多數狀況下，數組中的一部分空間並無被利用。

　　再來看看第二種方案，經過在第一個for循環中加入一個限定條件，能夠使問題獲得解決。好比：for (int n = 0; cin >> num[n] && n < max_size; n ++); 可是這個方案一樣不甚理想，儘管不會使程序崩潰，但失去了靈活性，你沒法輸入更多的數。

　　看來只有選擇第三種方案了。是的，你能夠利用指針，以及動態內存分配妥善的解決上述問題，而且使程序具備良好的靈活性。這須要用到new，delete操做符，或者古老的malloc()，realloc()和free()函數。可是爲此，你將犧牲程序的簡潔性，使程序代碼陡增，代碼的處理邏輯也再也不像原先看起來那麼清晰了。一個compare函數或許就已經令你不耐煩了，更況且要實現這些複雜的處理機制呢？很難保證你不會在處理這個問題的時候出錯，不少程序的bug每每就是這樣產生的。同時，你還應該感謝stdlib.h，它爲你提供了qsort函數，不然，你還須要本身實現排序算法。若是你用的是冒泡法排序，那效率就不會很理想。……，問題真是愈來愈讓人頭疼了！

　　關於第一個程序的討論就到此爲止，若是你對第三種方案感興趣的話，能夠嘗試着本身編寫一個程序，做爲思考題。這裏就不許備再浪費筆墨去實現這樣一個讓人不甚愉快的程序了。

2.2.2 第二版：工業時代--組件化大生產

　　咱們應該慶幸本身所生活的年代。工業時代，科技的發展所帶來的巨大便利已經影響到了咱們生活中的每一個細節。若是你還在以原始人類的方式生活着，那我真該懷疑你是否屬於某個生活在非洲或者南美叢林裏的原始部落中的一員了，難道是瑪雅文明又重現了？

　　STL即是這個時代的產物，正如其餘科技成果同樣，C++程序員也應該努力使本身適應並充分利用這個"高科技成果"。讓咱們從新審視初版的那個破爛不堪的程序。試着使用一下STL，看看效果如何。

 

 1 // name:example2_2.cpp
 2 // alias:The first STL program
 3 
 4 #include <iostream>
 5 #include <vector>
 6 #include <algorithm>
 7 
 8 using namespace std;
 9 
10 void main(void)
11 {
12     vector<int> num;        // STL中的vector容器
13     int element;
14 
15     // 從標準輸入設備讀入整數， 
16     // 直到輸入的是非整型數據爲止
17     while (cin >> element)
18         num.push_back(element);
19 
20     // STL中的排序算法
21     sort(num.begin(), num.end());
22 
23     // 將排序結果輸出到標準輸出設備
24     for (int i = 0; i < num.size(); i ++)
25         cout << num[i] << "\n";
26 }
27      

 

　　這個程序的主要部分改用了STL的部件，看起來要比第一個程序簡潔一點，你已經找不到那個討厭的compare函數了。它真的能很好的運行嗎？你能夠試試，由於程序的運行結果和前面的大體差很少，因此在此略去。我能夠向你保證，這個程序是足夠健壯的。不過，可能你尚未徹底看明白程序的代碼，因此我須要爲你解釋一下。畢竟，這個戲法變得太快了，較之第一個程序，一眨眼的功夫，那些老的C++程序員所熟悉的代碼都不見了，取而代之的是一些新鮮玩意兒。

　　程序的前三行是包含的頭文件，它們提供了程序所要用到的全部C++特性（包括輸入輸出處理，STL中的容器和算法）。沒必要在乎那個.h，並非個人疏忽，程序保證能夠編譯經過，只要你的C++編譯器支持標準C++規範的相關部分。你只須要把它們看做是一些普通的C++頭文件就能夠了。事實上，也正是如此，若是你對這個變化細節感興趣的化，能夠留意一下你身旁的佐餐。

　　一樣能夠忽略第四行的存在。加入那個聲明只是爲了代表程序引用到了std這個標準名字空間（namespace），由於STL中的那些玩意兒全都包含在那裏面。只有經過這行聲明，編譯器才能容許你使用那些有趣的特性。

　　程序中用到了vector，它是STL中的一個標準容器，能夠用來存放一些元素。你能夠把vector理解爲int [?]，一個整型的數組。之因此大小未知是由於，vector是一個能夠動態調整大小的容器，當容器已滿時，若是再放入元素則vector會悄悄擴大本身的容量。push_back是vector容器的一個類屬成員函數，用來在容器尾端插入一個元素。main函數中第一個while循環作的事情就是不斷向vector容器尾端插入整型數據，同時自動維護容器空間的大小。

　　sort是STL中的標準算法，用來對容器中的元素進行排序。它須要兩個參數用來決定容器中哪一個範圍內的元素能夠用來排序。這裏用到了vector的另兩個類屬成員函數。begin()用以指向vector的首端，而end()則指向vector的末端。這裏有兩個問題，begin()和end()的返回值是什麼？這涉及到STL的另外一個重要部件--迭代器（Iterator），不過這裏並不須要對它作詳細瞭解。你只須要把它看成是一個指針就能夠了，一個指向整型數據的指針。相應的sort函數聲明也能夠看做是void 　　sort(int* first, int* last)，儘管這實際上很不精確。另外一個問題是和end()函數有關，儘管前面說它的返回值指向vector的末端，但這種說法不能算正確。事實上，它的返回值所指向的是vector中最末端元素的後面一個位置，即所謂pass-the-end value。這聽起來有點費解，不過沒必要在乎，這裏只是稍帶一提。總的來講，sort函數所作的事情是對那個準整型數組中的元素進行排序，一如第一個程序中的那個qsort，不過比起qsort來，sort彷佛要簡單了許多。

　　程序的最後是輸出部分，在這裏vector徹底能夠以假亂真了，它所提供的對元素的訪問方式簡直和普通的C++內建數組如出一轍。那個size函數用來返回vector中的元素個數，就至關於第一個程序中的變量n。這兩行代碼直觀的不用我再多解釋了。

　　我想個人耐心講解應該能夠使你大體看懂上面的程序了，事實上STL的運用使程序的邏輯更加清晰，使代碼更易於閱讀。試問，有誰會不明白begin、end、size這樣的字眼所表達的含義呢（除非他不懂英語）？試着運行一下，看看效果。再試着多輸入幾個數，看看是否會發生數組越界現象。實踐證實，程序運行良好。是的，因爲vector容器自行維護了自身的大小，C++程序員就不用操心動態內存分配了，指針的錯誤使用畢竟會帶來不少麻煩，同時程序也會變得冗長無比。這正是前面第三種方案的缺點所在。

　　再仔細審視一下你的第一個STL版的C++程序，回顧一下第一章所提到的那些有關STL的優勢：易於使用，具備工業強度……，再比較一下初版的程序，我想你應該有所體會了吧！

2.2.3 第三版：惟美主義的傑做

　　事態的發展有時候總會趨向極端，這在那些惟美主義者當中猶是如此。首先聲明，我並非一個惟美主義者，提供第二版程序的改進版，徹底是爲了讓你更深入的感覺到STL的魅力所在。在看完第三版以後，你會強烈感覺到這一點。或許你也會變成一個惟美主義者了，至少在STL方面。這應該不是個人錯，由於決定權在你手裏。下面咱們來看看這個絕版的C++程序。

 

 1 // name:example2_3.cpp
 2 // alias:aesthetic version
 3 
 4 #include <iostream>
 5 #include <vector>
 6 #include <algorithm>
 7 #include <iterator>
 8 
 9 using namespace std;
10 
11 void main(void)
12 {
13     typedef vector<int>                int_vector;
14     typedef istream_iterator<int>                istream_itr;
15     typedef ostream_iterator<int>                ostream_itr;
16     typedef back_insert_iterator< int_vector >    back_ins_itr;
17 
18     // STL中的vector容器
19     int_vector num;
20 
21     // 從標準輸入設備讀入整數， 
22     // 直到輸入的是非整型數據爲止
23     copy(istream_itr(cin), istream_itr(), back_ins_itr(num));
24 
25     // STL中的排序算法
26     sort(num.begin(), num.end());
27 
28     // 將排序結果輸出到標準輸出設備
29     copy(num.begin(), num.end(), ostream_itr(cout, "\n"));
30 }

 

 　　在這個程序裏幾乎每行代碼都是和STL有關的（除了main和那對花括號，固然還有註釋），而且它包含了STL中幾乎全部的各大部件（容器container，迭代器iterator, 算法algorithm, 適配器adaptor），惟一的遺憾是少了函數對象（functor）的身影。

　　還記得開頭提到的一個典型系統所具備的基本特徵嗎？--輸入+處理+輸出。全部這些功能，在上面的程序裏，僅僅是經過三行語句來實現的，其中每一行語句對應一種操做。對於數據的操做被高度的抽象化了，而算法和容器之間的組合，就像搭積木同樣輕鬆自如，系統的耦合度被降到了極低點。這就是閃耀着泛型之光的STL的偉大力量。如此簡潔，如此巧妙，如此神奇！就像魔術通常，以致於再一次讓你摸不着頭腦。怎麼實現的？爲何在看第二版程序的時候如此清晰的你，又墜入了五里霧中（竊喜）。

　　請留意此處的標題（惟美主義的傑做），在實際環境中，你未必要作到這樣完美。畢竟美好願望的破滅，在生活中時常會發生。過於理想化，並非一件好事，至少我是這麼認爲的。正如前面提到的，這個程序只是爲了展現STL的獨特魅力，你不得不爲它的出色表現所折服，也許只有深諳STL之道的人才會想出這樣的玩意兒來。若是你只是通常性的使用STL，作到第二版這樣的程度也就能夠了。

　　實在是由於這個程序太過"簡單"，以致於我沒法確定，在你尚未徹底掌握STL以前，經過個人講解，是否可以領會這區區三行代碼，我將盡個人最大努力。

　　前面提到的迭代器能夠對容器內的任意元素進行定位和訪問。在STL裏，這種特性被加以推廣了。一個cin表明了來自輸入設備的一段數據流，從概念上講它對數據流的訪問功能相似於通常意義上的迭代器，可是C++中的cin在不少地方操做起來並不像是一個迭代器，緣由就在於其接口和迭代器的接口不一致（好比：不能對cin進行++運算，也不能對之進行取值運算--即*運算）。爲了解決這個矛盾，就須要引入適配器的概念。istream_iterator即是一個適配器，它將cin進行包裝，使之看起來像是一個普通的迭代器，這樣咱們就能夠將之做爲實參傳給一些算法了（好比這裏的copy算法）。由於算法只認得迭代器，而不會接受cin。對於上面程序中的第一個copy函數而言，其第一個參數展開後的形式是：istream_iterator(cin)，其第二個參數展開後的形式是：istream_iterator()（若是你對typedef的語法不清楚，能夠參考有關的c++語言書籍）。其效果是產生兩個迭代器的臨時對象，前一個指向整型輸入數據流的開始，後一個則指向"pass-the-end value"。這個函數的做用就是將整型輸入數據流從頭到尾逐一"拷貝"到vector這個準整型數組裏，第一個迭代器從開始位置每次累進，最後到達第二個迭代器所指向的位置。或許你要問，若是那個copy函數的行爲真如我所說的那樣，爲何不寫成以下這個樣子呢？

 

1 copy(istream_iterator<int>(cin), istream_iterator<int>(), num.begin());

 

　　你確實能夠這麼作，可是有一個小小的麻煩。還記得初版程序裏的那個數組越界問題嗎？若是你這麼寫的話，就會遇到相似的麻煩。緣由在於copy函數在"拷貝"數據的時候，若是輸入的數據個數超過了vector容器的範圍時，數據將會拷貝到容器的外面。此時，容器不會自動增加容量，由於這只是簡單地拷貝，並非從末端插入。爲了解決這個問題，另外一個適配器back_insert_iterator登場了，它的做用就是引導copy算法每次在容器末端插入一個數據。程序中的那個back_ins_itr(num)展開後就是：back_insert_iterator<int_vector>(num)，其效果是生成一個這樣的迭待器對象。

　　終於將講完了三分之一（真不容易！），好在第二句和前一版程序沒有差異，這裏就略過了。至於第三句，ostream_itr(cout, "\n")展開後的形式是：ostream_iterator(cout, "\n")，其效果是產生一個處理輸出數據流的迭待器對象，其位置指向數據流的起始處，而且以"\n"做爲分割符。第二個copy函數將會從頭到尾將vector中的內容"拷貝"到輸出設備，第一個參數所表明的迭代器將會從開始位置每次累進，最後到達第二個參數所表明的迭代器所指向的位置。

　　這就是所有的內容。

2.3 歷史的評價

　　歷史的車輪老是滾滾向前的，工業時代的文明較之史前時代，固然是先進而且發達的。回顧那兩個時代的C++程序，你會真切的感覺到這種差異。簡潔易用，具備工業強度，較好的可移植性，高效率，加之第三個使人目眩的絕版程序所體現出來的高度抽象性，高度靈活性和組件化特性，使你對STL背後所蘊含的泛型化思想都有了些微的感覺。

　　真幸運，你能夠橫跨兩個時代，有機會目擊這種"文明"的差別。同時，這也應該使你越加堅決信念，使本身順應時代的潮流。