導讀
你已經熟悉了STL。你知道怎么建立容器，迭代它們的內容，添加刪除元素和應用常見算法，比如find和sort。但你并不
滿足，你不能擺脫STL所提供的超過它們能帶來的好處的感覺。應該簡單的任務并非那樣。應該直截了當的操作確有資
源泄漏或錯誤行為。應該高效的過程卻需要比你希望給它們的更多的時間和內存。是的，你知道怎么使用STL，但你不
確定你在有效地使用它。
我為你寫了這本書。
在《Effective STL》中，我解釋了怎樣結合STL組件來在庫的設計得到最大的好處。這樣的信息允許你對簡單、直接的問
題開發簡單、直接的解決方案，也幫你對更復雜的問題設計優雅的方法。我描述了常見的STL使用錯誤，而且向你演示
怎么避開它們。那幫助你躲開閃資源漏、不可移植的代碼和未定義的行為。我討論了優化代碼的方法，所以你能使STL
表現得像它應該的那樣快速、光滑。
本書里的信息將使你成為一個更好的STL程序員，它將讓你成為一個更高產的程序員。而且它將讓你成為一個更愉快的
程序員，使用STL很有趣，但是有效地使用它更為有趣，這種有趣是它們必須把你拽離鍵盤，因為你不能相信你爭擁有
的好時光。即使對STL的匆匆一瞥也能發現它是一個非常酷的庫，但這份酷比你可能想象的更寬更深。我在本書的一個
主要目標是傳達給你這個庫有多神奇，因為在我編程的差不多30年里，我從未見過任何像STL的東西。你或許也沒有。
定義、使用和擴展STL
沒有“STL”的官方定義，而且當人們使用這個術語時，不同的人表示的是不同的東西。在本書中，“STL”的意思是
與迭代器合作的C++標準庫的一部分。那包括標準容器（包括string），iostream庫的一部分，函數對象和算法。它不包
括標準容器適配器（stack、queue和priority_queue）以及bitset和valarray容器，因為它們缺乏迭代器支持。它也不包括數
組。真的，數組以指針的形式支持迭代器，但數組是C++語言的一部分，并非庫。
技術上，我的STL的定義排除了標準C++庫的擴展，特別是散列容器，單鏈表，rope和多種非標準函數對象。雖然如
此，一個有效的STL程序員需要知道這樣的擴展，因此我在合適的地方提到了它們。的確，條款25致力于非標準散列容
器的概述。它們現在不在STL里，但類似它們的東西幾乎肯定將要進入標準C++庫的下一個版本，而在窺見未來是有價
值的。
存在STL擴展的原因之一是STL是被設計為可擴展的庫。不過，在本書里，我關注于使用STL，而不是給它添加新的組
件。例如，如果你發現，我沒有說多少關于寫你自己的算法的東西，而且我根本沒有在寫新容器和迭代器上提供指導。
我相信在你著手增加它的能力之前，掌握STL已經提供的東西很重要，所以那是我在《Effective STL》里關注的。當你決
定建立你自己STLesque組件時，你將在像Josuttis的《The C++ Standard Library》[3]和Austern的《Generic Programming and
the STL》[4]這樣的書里找到建議。我確實在這本書里討論的STL擴展的一個方面是寫你自己的函數對象。你不可能在不
知道怎么寫自己的函數對象的情況下有效地使用STL，所以我為這個主題投入了整整一章（第6章）。

STL和標準
我經常提及C++標準，因為《Effective STL》專注于可移植的，與標準一致的C++。理論上，我在這本書里演示的一切都
可以用于每個C++實現。實際上，那不是真的。編譯器的缺陷和STL實現湊合成防止一些有效的代碼編譯或表現出它們
應該有的行為。那是很常見的情況，我描述了這些問題，而且解釋了你應該怎么變通地解決他們。
有時候，最容易的變通辦法是使用另一個STL實現。附錄B給一個這種情況的例子。實際上，STL用得越多，編譯器和庫
實現的區別就越重要。程序員在設法讓合法的代碼編譯時遇到困難，他們通常責備他們的編譯器，但對于STL，編譯器
可能是好的，而STL實現是不良的。為了強調你得依賴編譯器和庫實現的事實，我使用你的STL平臺。一個STL平臺是一
個特定編譯器和一個標準模板庫特定實現的組合。在本書里，如果我提及一個編譯器問題，你能確信我意思是編譯器有
問題。但是，如果我說你的STL平臺有問題，你應該理解為“可能是編譯器缺陷，可能是庫缺陷，或許都有”。
我一般提及你的“編譯器們”——復數。那是我長期相信你通過確保代碼可以在多于一個的編譯器上工作的方法來改進
你的代碼質量（特別是移植性）的產物。此外，使用多個編譯器一般可以簡化拆解由STL的使用不當造成的錯誤信息難
題。（條款49致力于解碼此類消息的方法。）
關于與標準一致的代碼，我強調的另一個方面是你應該避免構造未定義行為。這樣的構造可能在運行期做任何事情。不
幸的是，這意味著它們可能正好做了你想要的，而那會導致一種錯誤的安全感。太多程序員以為未定義行為總會導致一
個明顯的問題，例如，一個分段錯誤或其他災難性的錯誤。未定義行為的結果實際上更為狡猾，例如，破壞極少引用的
數據。它們也可以通過程序運行。我發現一個未定義行為的好定義是“為我工作，為你工作，在開發和QA期間工作，
但在你最重要的用戶面前爆炸了”。避免未定義行為很重要，所以我指出了它會出現的通常情況。你應該訓練你自己警
惕這樣的情況。