05年的文章，從網易引來，但源頭是CSDN。
作爲C++標準不可缺少的一部分，STL應該是滲透在C++程序的角角落落裏的。STL不是實驗室裏的寵兒，也不是程序員桌上的擺設，她的激動人心並非曇花一現。本教程旨在傳播和普及STL的基礎知識，若能藉此機會爲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的一篇專訪。
在結識新朋友的時候，大多數人總是忍不住想了解對方的過去。本節將帶您簡單回顧一下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++標準中不可或缺的一大部件。
在你瞭解了STL的過去之後，一些名詞開始不斷在你的大腦中浮現，STL、C++、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中的一些算法在處理特殊情形時可以選擇非一般化的方式，從而保證了執行的效率。
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++標準函數庫
正如前面所提到的，在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會是什麼樣子，似乎沒有人做過這樣的試驗。
相信你對STL的感性認識應該有所提高了，是該做一些實際的工作了，那麼我們首先來了解一下STL的不同實現版本。ANSI/ISO C++文件中的STL是一個僅被描述在紙上的標準，對於諸多C++編譯器而言，需要有各自實際的STL，它們或多或少的實現了標準中所描述的內容，這樣才能夠爲我們所用。之所以有不同的實現版本，則存在諸多原因，有歷史的原因，也有各自編譯器生產廠商的原因。以下是幾個常見的STL實現版本。
HP STL是所有其它STL實現版本的根源。它是STL之父Alexander Stepanov在惠普的Palo Alto實驗室工作時，和Meng Lee共同完成的，是第一個STL的實現版本（參見1.2節）。這個STL是開放源碼的，所以它允許任何人免費使用、複製、修改、發佈和銷售該軟件和相關文檔，前提是必須在所有相關文件中加入HP STL的版本信息和授權信息。現在已經很少直接使用這個版本的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.comVisualStudiohashset容器。
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源代碼C:Program Files\Borland\Cbuilder6\Include\oldstl）。
STLport最初源於俄國人Boris Fomitchev的一個開發項目，主要用於將SGI STL的基本代碼移植到其他諸如C++Builder或者是Visual C++這樣的主流編譯器上。因爲SGI STL屬於開放源碼，所以STLport纔有權這樣做。目前STLport的最新版本是4.5。可以從如下網站得到更詳細的情況介紹：http://www.stlport.org免費下載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）。
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家族的譜系
如果你是一個純粹的實用主義者，也許一開始就可以從這裏開始看起，因爲此處提供了一個示例程序，它可以帶給你有關使用STL的最直接的感受。是的，與其紙上談兵，不如單刀直入，實際操作一番。但是，需要提醒的是，假如你在興致昂然地細細品味本章內容的時候，能夠同時結合前面章節作爲佐餐，那將是再好不過的。你會發現，前面所提到的有關STL的那些優點，在此處得到了確切的應證。本章的後半部分，將爲你演示在一些主流C++編譯器上，運行上述示例程序的具體操作方法，和需要注意的事項。
非常遺憾，我不得不捨棄"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的細節，這裏恐怕沒有你希望得到的答案，你可以尋找其它相關書籍。
在STL還沒有降生的"黑暗時代"，C++程序員要完成前面所提到的那些功能，需要做很多事情（不過這比起C程序來，似乎好一點），程序大致是如下這個樣子的：
// name:example2_1.cpp
// alias:Rubish
#include <stdlib.h>
#include <iostream.h>
int compare(const void *arg1, const void *arg2);
void main(void)
{
const int max_size = 10; // 數組允許元素的最大個數
int num[max_size]; // 整型數組
// 從標準輸入設備讀入整數，同時累計輸入個數，
// 直到輸入的是非整型數據爲止
int n;
for (n = 0; cin >> num[n]; n ++);
// C標準庫中的快速排序（quick-sort）函數
qsort(num, n, sizeof(int), compare);
// 將排序結果輸出到標準輸出設備
for (int i = 0; i < n; i ++)
cout << num[i] << "\n";
}
// 比較兩個數的大小，
// 如果*(int *)arg1比*(int *)arg2小，則返回-1
// 如果*(int *)arg1比*(int *)arg2大，則返回1
// 如果*(int *)arg1等於*(int *)arg2，則返回0
int compare(const void *arg1, const void *arg2)
{
return (*(int *)arg1 < *(int *)arg2) ? -1 :
(*(int *)arg1 > *(int *)arg2) ? 1 : 0;
}
這是一個和STL沒有絲毫關係的傳統風格的C++程序。因爲程序的註釋已經很詳盡了，所以不需要我再做更多的解釋。總的說來，這個程序看起來並不十分複雜（本來就沒有太多功能）。只是，那個compare函數，看起來有點費勁。指向它的函數指針被作爲最後一個實參傳入qsort函數，qsort是C程序庫stdlib.h中的一個函數。以下是qsort的函數原型：
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，看看效果如何。
// name:example2_2.cpp
// alias:The first STL program
#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;
void main(void)
{
vector<int> num; // STL中的vector容器
int element;
// 從標準輸入設備讀入整數，
// 直到輸入的是非整型數據爲止
while (cin >> element)
num.push_back(element);
// STL中的排序算法
sort(num.begin(), num.end());
// 將排序結果輸出到標準輸出設備
for (int i = 0; i < num.size(); i ++)
cout << num[i] << "\n";
}
這個程序的主要部分改用了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++程序。
// name:example2_3.cpp
// alias:aesthetic version
#include <iostream>
#include <vector>
#include <algorithm>
#include <iterator>
using namespace std;
void main(void)
{
typedef vector<int> int_vector;
typedef istream_iterator<int> istream_itr;
typedef ostream_iterator<int> ostream_itr;
typedef back_insert_iterator< int_vector > back_ins_itr;
// STL中的vector容器
int_vector num;
// 從標準輸入設備讀入整數，
// 直到輸入的是非整型數據爲止
copy(istream_itr(cin), istream_itr(), back_ins_itr(num));
// STL中的排序算法
sort(num.begin(), num.end());
// 將排序結果輸出到標準輸出設備
copy(num.begin(), num.end(), ostream_itr(cout, "\n"));
}
在這個程序裏幾乎每行代碼都是和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函數的行爲真如我所說的那樣，爲什麼不寫成如下這個樣子呢？
copy(istream_iterator<int>(cin), istream_iterator<int>(), num.begin()); 你確實可以這麼做，但是有一個小小的麻煩。還記得第一版程序裏的那個數組越界問題嗎？如果你這麼寫的話，就會遇到類似的麻煩。原因在於copy函數在"拷貝"數據的時候，如果輸入的數據個數超過了vector容器的範圍時，數據將會拷貝到容器的外面。此時，容器不會自動增長容量，因爲這只是簡單地拷貝，並不是從末端插入。爲了解決這個問題，另一個適配器back_insert_iterator登場了，它的作用就是引導copy算法每次在容器末端插入一個數據。程序中的那個back_ins_itr(num)展開後就是：back_insert_iterator(num)，其效果是生成一個這樣的迭待器對象。
終於將講完了三分之一（真不容易！），好在第二句和前一版程序沒有差別，這裏就略過了。至於第三句，ostream_itr(cout, "\n")展開後的形式是：ostream_iterator(cout, "\n")，其效果是產生一個處理輸出數據流的迭待器對象，其位置指向數據流的起始處，並且以"\n"作爲分割符。第二個copy函數將會從頭至尾將vector中的內容"拷貝"到輸出設備，第一個參數所代表的迭代器將會從開始位置每次累進，最後到達第二個參數所代表的迭代器所指向的位置。
這就是全部的內容。
歷史的車輪總是滾滾向前的，工業時代的文明較之史前時代，當然是先進並且發達的。回顧那兩個時代的C++程序，你會真切的感受到這種差別。簡潔易用，具有工業強度，較好的可移植性，高效率，加之第三個令人目眩的絕版程序所體現出來的高度抽象性，高度靈活性和組件化特性，使你對STL背後所蘊含的泛型化思想都有了些微的感受。
真幸運，你可以橫跨兩個時代，有機會目睹這種"文明"的差異。同時，這也應該使你越加堅定信念，使自己順應時代的潮流。
事態的發展有時候總會趨向極端，這在那些唯美主義者當中猶是如此。首先聲明，我並不是一個唯美主義者，提供第二版程序的改進版，完全是爲了讓你更深刻的感受到STL的魅力所在。在看完第三版之後，你會強烈感受到這一點。或許你也會變成一個唯美主義者了，至少在STL方面。這應該不是我的錯，因爲決定權在你手裏。下面我們來看看這個絕版的C++程序。
// name:example2_3.cpp
// alias:aesthetic version
#include <iostream>
#include <vector>
#include <algorithm>
#include <iterator>
using namespace std;
void main(void)
{
typedef vector<int> int_vector;
typedef istream_iterator<int> istream_itr;
typedef ostream_iterator<int> ostream_itr;
typedef back_insert_iterator< int_vector > back_ins_itr;
// STL中的vector容器
int_vector num;
// 從標準輸入設備讀入整數，
// 直到輸入的是非整型數據爲止
copy(istream_itr(cin), istream_itr(), back_ins_itr(num));
// STL中的排序算法
sort(num.begin(), num.end());
// 將排序結果輸出到標準輸出設備
copy(num.begin(), num.end(), ostream_itr(cout, "\n"));
}
在這個程序裏幾乎每行代碼都是和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函數的行爲真如我所說的那樣，爲什麼不寫成如下這個樣子呢？
copy(istream_iterator<int>(cin), istream_iterator<int>(), num.begin()); 你確實可以這麼做，但是有一個小小的麻煩。還記得第一版程序裏的那個數組越界問題嗎？如果你這麼寫的話，就會遇到類似的麻煩。原因在於copy函數在"拷貝"數據的時候，如果輸入的數據個數超過了vector容器的範圍時，數據將會拷貝到容器的外面。此時，容器不會自動增長容量，因爲這只是簡單地拷貝，並不是從末端插入。爲了解決這個問題，另一個適配器back_insert_iterator登場了，它的作用就是引導copy算法每次在容器末端插入一個數據。程序中的那個back_ins_itr(num)展開後就是：back_insert_iterator(num)，其效果是生成一個這樣的迭待器對象。
終於將講完了三分之一（真不容易！），好在第二句和前一版程序沒有差別，這裏就略過了。至於第三句，ostream_itr(cout, "\n")展開後的形式是：ostream_iterator(cout, "\n")，其效果是產生一個處理輸出數據流的迭待器對象，其位置指向數據流的起始處，並且以"\n"作爲分割符。第二個copy函數將會從頭至尾將vector中的內容"拷貝"到輸出設備，第一個參數所代表的迭代器將會從開始位置每次累進，最後到達第二個參數所代表的迭代器所指向的位置。
這就是全部的內容。
歷史的車輪總是滾滾向前的，工業時代的文明較之史前時代，當然是先進並且發達的。回顧那兩個時代的C++程序，你會真切的感受到這種差別。簡潔易用，具有工業強度，較好的可移植性，高效率，加之第三個令人目眩的絕版程序所體現出來的高度抽象性，高度靈活性和組件化特性，使你對STL背後所蘊含的泛型化思想都有了些微的感受。
真幸運，你可以橫跨兩個時代，有機會目睹這種"文明"的差異。同時，這也應該使你越加堅定信念，使自己順應時代的潮流。
2.4 如何運行
在你還沒有真正開始運行前面後兩個程序之前，最好先瀏覽一下本節。這裏簡單介紹了在特定編譯器環境下運行STL程序的一些細節，並提供了一些可能遇到的問題的解決辦法。
此處，我選用了目前在Windows平臺下較爲常見的Microsoft Visual C++ 6.0和Borland C++ Builder 6.0作爲例子。儘管Visual C++ 6.0對最新的ANSI/ISO C++標準支持的並不是很好。不過據稱Visual C++ .NET（也就是VC7.0）在這方面的性能有所改善。
你可以選用多種方式運行前面的程序，比如在Visual C++下，你可以直接在DOS命令行狀態下編譯運行，也可以在VC的IDE下采用控制檯應用程序（Console Application）的方式運行。對於C++ Builder，情況也類似。
對於Visual C++而言，如果是在DOS命令行狀態下，你首先需要找到它的編譯器。假定你的Visual C++裝在C:\Program Files\Microsoft Visual Studio\VC98下面，則其編譯器所在路徑應該是C:\Program Files\Microsoft Visual Studio\VC98\Bin，在那裏你可以找到cl.exe文件。編譯時請加上/GX和/MT參數。如果一切正常，結果就會產生一個可執行文件。如下所示：
cl /GX /MT example2_2.cpp
前一個參數用於告知編譯器允許異常處理（Exception Handling）。在P. J. Plauger STL中的很多地方使用了異常處理機制（即try…throw…catch語法），所以應該加上這個參數，否則會有如下警告信息：
warning C4530: C++ exception handler used, but unwind semantics are not enabled.
後一個參數則用於使程序支持多線程，它需要在鏈接時使用LIBCMT.LIB庫文件。不過P. J. Plauger STL並不是線程安全的（thread safety）。如果你是在VC環境下使用像STLport這樣的STL實現版本，則需要加上這個參數，因爲STLport是線程安全的。
如果在IDE環境下，可以在新建工程的時候選擇控制檯應用程序。
圖3：在Visual C++ IDE環境下運行STL程序
至於那些參數的設置，則可以通過在Project功能菜單項中的Settings功能【Alt+F7】中設置編譯選項來完成。
圖4：在Visual C++ IDE環境下設置編譯參數
有時，在IDE環境下編譯STL程序時，可能會出現如下警告信息（前面那幾個示例程序不會出現這種情況）：
warning C4786: '……' : identifier was truncated to '255' characters in the debug information
這是因爲編譯器在Debug狀態下編譯時，把程序中所出現的標識符長度限制在了255個字符範圍內。如果超過最大長度，這些標識符就無法在調試階段查看和計算了。而在STL程序中大量的用到了模板函數和模板類，編譯器在實例化這些內容時，展開之後所產生的標識符往往很長（沒準會有一千多個字符！）。如果你想認識一下這個warning的話，很簡單，在程序里加上如下一行代碼：
vector<string> string_array; // 類似於字符串數組變量
對於這樣的warning，當然可以置之不理，不過也是有解決辦法的。 你可以在文件開頭加入下面這一行：#pragma warning(disable: 4786)。它強制編譯器忽略這個警告信息，這種做法雖然有點粗魯，但是很有效。
至於C++ Builder，其DOS命令行狀態下的運行方式是這樣的。假如你的C++ Builder裝在C:\Program Files\Borland\CBuilder6。則其編譯器所在路徑應該是C:\Program Files\ Borland\CBuilder6\Bin，在那裏你可以找到bcc32.exe文件，輸入如下命令，即大功告成了：
bcc32 example2_2.cpp
至於IDE環境下，則可以在新建應用程序的時候，選擇控制檯嚮導（Console Wizard）。
圖5：在C++ Builder IDE環境下運行STL程序
現在你可以在你的機器上運行前面的示例程序了。不過，請恕我多嘴，有些細節不得不提請你注意。小心編譯器給你留下的陷阱。比如前面第三個程序中有如下這一行代碼：
typedef back_insert_iterator< int_vector > back_ins_itr;
請留意">"前面的空格，最好不要省去。如果你吝惜這點空格所佔用的磁盤空間的話，那就太不划算了。其原因還是在於C++編譯器本身的缺陷。上述代碼，相當於如下代碼（編譯器做的也正是這樣的翻譯工作）：
typedef back_insert_iterator< vector<int> > back_ins_itr;
如果你沒有加空格的話，編譯器會把">>"誤認爲是單一標識（看起來很像那個數據流輸入操作符">>"）。爲了迴避這個難題，C++要求使用者必須在兩個右尖括號之間插入空格。所以，你最好還是老老實實照我的話做，以避免不必要的麻煩。不過有趣的是，對於上述那行展開前的代碼，在Visual C++裏即使你沒有加空格，編譯器也不會報錯。而同樣的代碼在C++ Builder中沒有那麼幸運了。不過，最好還是不要心存僥倖，如果你採用展開後的書寫方式，則兩個編譯器都不會給你留情面了。
好了，請原諒我的絮叨，現在你可以親身感受一下STL所帶給你的真正獨特魅力了，祝你好運！