STL 的string類怎么啦？陳皓

前言

上個周末在和我的同學爬香山閑聊時，同學說到STL中的string類曾經讓他備受折磨，幾年前他開發一個系統前對string類還比較清楚，然后隨著程序的復雜度的加深，到了后期，他幾乎對string類失去了信心和信任，他覺得他對string類一頭霧水。老實說，我幾年前也有同樣的痛苦（就是當我寫下《標準C＋＋類string的Copy-On-Write技術》之前的一段時間）。那時，我不得不研究那根本不是給人看的SGI出品的string類的源碼，代碼的可讀性幾乎為零，而且隨著了解越深入，就越覺得C++的世界中到處都是陷阱和缺陷。越來越覺得有時候那些類并不像自己所想象的那樣工作。

為什么會發生這樣的情況呢？string類只是一個“簡單”的類，如果是一些比較復雜的類呢？而這幾年來，C++陣營聲討標準模板庫中的標準string類愈演愈烈。C++陣營對這個“小子”的爭討就沒有停止過。相信在下一個C++的標準出臺時，string類會有一個大的變化。

了解string類

在我們研究string類犯了什么毛病之前，還讓我先說一下如何了解一個C++的類。我們要了解一個C++的類，一般來說，要從三個方面入手。

一、意圖（Intention）。知其然還要知所以然，string類的意圖是什么？只有了解了意圖，才知道它的思路。這是了解一個事物最重要最根本的部分。不然，你會發現它的行為并不會像你所期望的那樣。string類的意義有兩個，第一個是為了處理char類型的數組，并封裝了標準C中的一些字符串處理的函數。而當string類進入了C++標準后，它的第二個意義就是一個容器。這兩件事并不矛盾，我們要需理解string的機制，需要從這兩個方面考慮。

二、規格（Specification）。我們注意到string類有太多的接口函數。這是目前C++陣營中聲討其最重的話題。一個小小的string類居然有106個成員接口函數。居然，C++標準委員會會容忍這種“ugly”的事情的發生？目前的認為導致“C++標準委員會腦子進水”的主流原因有兩點，一個是為了提高效率，另一個是為了常用的操作。

1）讓我們先來看效率，看看string類中的“==”操作符重載接口：

bool operator==(const string& lhs, const string& rhs);
bool operator==(const string& lhs, const char* rhs);
bool operator==(const char* lhs, const string& rhs);

頭一個很標準，而后兩個似乎就顯得沒有必要了。如果我們調用：（Str == “string”）如果沒有后面兩個接口，string的構造函數會把char*的 ”string”轉成string對象，然后再調用第一個接口，也就是 operator==(str, string(“string”))。如此“多余”的設計只能說是為了追求效率，為了省去調用構造/析構函數和分配/釋放內存的時間（這會節省很多的時間）。在后面兩個接口中，直接使用了C的strcmp函數。如此看來，這點設計還是很有必要的。string類中有很多為了追求效率的算法和設計，比如：Copy-on-Write（參看我的《標準C＋＋類string的Copy-On-Write技術》）等。這些東西讓我們的string變得很有效率，但也帶來了陷阱。如果不知道這些東西，那么當你使用它的時候發生不可意料的問題，就會讓你感到迷茫和不知所措。

2）另一個讓string類擁有這么龐大的接口的原因是常用的操作。比如string類的substr()，這是一個截取子字符串的函數。其實這個函數并不需要，因為string有一個構造函數可以從別的string類中指定其起始和長度構造自己，從而實現這一功能。還有就是copy()函數，這也是一個沒有必要的函數，copy這個函數把string類中的內容拷貝到一個內存buffer中，這個方法實踐證明很少有人使用。可能，1）為了安全起見，需要有這樣一個成員把內容復制出去；2）設計者覺得copy要比strcpy或是memcpy好寫也漂亮很多吧。copy()比起substr()更沒有必要存在。

三、實現（Implementation）。C++標準并沒有過多的干預實現。不同的產商會有不同的實現。不同的產商會考慮標準中的一件事情是否符合市場的需要，并要考慮自己的編譯器是否有能夠編譯標準的功能。于是，他們總是會輕微或是顛覆地修改著標準。C++在編譯器的差異是令人痛苦和絕望的，如果不了解具體的實現，在你使用C++的時候，你也會發現它并不像你所想象的那樣工作。

只有從上述三個方面入手，你才能真正了解一個C++類，而你也才能用好C++。C++高手們都是從這樣的三個方面剖析著C++現實中的各種類，并以此來驗證C++類的設計。

String類犯了什么錯？

string類其實挺好的。它的設計很有技術含量。它有高的效率、運行速度快、容易使用。它有很充足的接口可以滿足各式各樣的法，使用起來也很靈活。

然而，這個string類似乎有點沒有與時俱進，它現在的設計還保持著10年以前的樣子，10年來，整個技術環境都出現很多變革，人們也在使用C++的過程中得到了許許多的經驗。比如：現在的幾乎所有的程序都運行在一個多進/線程的環境中，而10年前主流還只是單進/線程的應用，這是一個巨大的變化。近幾年來，C++陣營也在實踐中取得了很多的經驗，特別是模板技術，而我們的STL顯然沒能跟上腳步。

       首當其沖的是string類，目前C++陣營對string類的聲討主要集中在下面幾個方面。對于下面的這些問題，C++陣營還是爭論不休。不過，作為一個好的程序員，我們應該在我們的設計和編程中注意一下這些方面。

1）目前的標string類有106個接口函數（包括構造和析構函數），如果考慮上默認參數，那么就一共有134不同的接口。其中有5個函數模板還會產生無窮多個各種各樣的函數。還有各種各樣的性能上的優化。在這么從多的成員函數中，很多都是冗余不必要的。最糟糕的是，眾多程序員們并不了解它們，導到要么浪費了它的優勢，要么踩中了其中的陷阱。

2）很多人認為string類提供的功能中，該有的沒有，已有的又很冗余。string類在同一個功能上實現了多次，而有一些功能卻沒有實現。如：大小寫不區分的比較，寬行字符（w_char）的支持，和字符char型數據的接口等等。

3）作為一個STL的容器，string類和的設計和其它容器基本一樣。這些STL都不鼓勵被繼承。因為STL容器的設計者們的幾乎都遺忘了虛函數的使用，這樣阻止了多態性，也許，這也是一個為了考慮效率和性能的設計。對于STL容易這樣的設計，大多數人表示接受。但對于string類，很多人認為，string類是一個特殊的類，考慮到它被使用的頻率，string類應該得到特殊的照顧。

4）還有很多人認為標準的strng類強行進行動態內存分配（malloc），那怕是一個很短的字符串。這會導致內存碎片問題（我們知道內存碎片問題會讓malloc很長時間才能返回，由于降低了整個程序的性能。而關于內存碎片問題，這是一個很嚴重的問題，目前除了重啟應用程序，還沒有什么好的方法）。他們認為，string類的設計加劇了內存碎片問題。他們希望string類能夠擁有自己的棧上內存來存放一些短字符串，而不需要總是去堆上分配內存。（因為用于string類的字符串長度幾乎都不會很長）

5）很多string類的實現，都采用了Copy-On-Write（COW）技術。雖然這是一個很有效率的技術。但是因為內存的共享，導致了程序在“多線程”環境中及容易發生錯誤，如果分別在兩個線程中的string實例共享著同一塊內存，很有可能發生潛在的內存問題（參看我的《標準C＋＋類string的Copy-On-Write技術》最后一節示例）。目前這一技術很有可能從下一版本的標準中移去。（而一些新版本的STL都不支持COW了，如Microsoft VC8.0下的STL）

6）標準的string類不支持policy-base技術的錯誤處理。string遇到錯誤時，只是簡單地拋出異常。雖然這是一個標準，但有一些情況下不會使用異常（GCC