STL 的string類怎么啦？陳皓

前言

上個周末在和我的同學爬香山閑聊時，同學說到STL中的string類曾經(jīng)讓他備受折磨，幾年前他開發(fā)一個系統(tǒng)前對string類還比較清楚，然后隨著程序的復雜度的加深，到了后期，他幾乎對string類失去了信心和信任，他覺得他對string類一頭霧水。老實說，我?guī)啄昵耙灿型瑯拥耐纯啵ň褪钱斘覍懴隆?A href="http://www.dhdzp.com/article/42859.htm" target=_blank>標準C＋＋類string的Copy-On-Write技術》之前的一段時間）。那時，我不得不研究那根本不是給人看的SGI出品的string類的源碼，代碼的可讀性幾乎為零，而且隨著了解越深入，就越覺得C++的世界中到處都是陷阱和缺陷。越來越覺得有時候那些類并不像自己所想象的那樣工作。

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

了解string類

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

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

二、規(guī)格（Specification）。我們注意到string類有太多的接口函數(shù)。這是目前C++陣營中聲討其最重的話題。一個小小的string類居然有106個成員接口函數(shù)。居然，C++標準委員會會容忍這種“ugly”的事情的發(fā)生？目前的認為導致“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的構造函數(shù)會把char*的 ”string”轉成string對象，然后再調用第一個接口，也就是 operator==(str, string(“string”))。如此“多余”的設計只能說是為了追求效率，為了省去調用構造/析構函數(shù)和分配/釋放內存的時間（這會節(jié)省很多的時間）。在后面兩個接口中，直接使用了C的strcmp函數(shù)。如此看來，這點設計還是很有必要的。string類中有很多為了追求效率的算法和設計，比如：Copy-on-Write（參看我的《標準C＋＋類string的Copy-On-Write技術》）等。這些東西讓我們的string變得很有效率，但也帶來了陷阱。如果不知道這些東西，那么當你使用它的時候發(fā)生不可意料的問題，就會讓你感到迷茫和不知所措。

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

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

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

String類犯了什么錯？

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

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

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

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

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

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

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

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

6）標準的string類不支持policy-base技術的錯誤處理。string遇到錯誤時，只是簡單地拋出異常。雖然這是一個標準，但有一些情況下不會使用異常（GCC –fno-exception）。另外，不可能要求所有的程序都要在使用string操作的時候try catch，一個比較好的方法是string類封裝有自己的error-handling函數(shù)，并且可以讓用戶來定義需要使用哪一種錯誤處理機制。

 
由于string類的的種種不如人意，特別是106個接口函數(shù)讓許多人難以接受，有很多人都在寫適合自己的string類。但總體來說，標準的string類是一個好壞難辨的類。無論你是否是一個高級咨深的程序員，你都會用到它。它和整個C++一樣，都是一把雙刃劍，在大多數(shù)情況下，它還是值得我們信賴。

目前，對string類的爭論有很多很多。C++標準委員會也說：“The C++ Standard is the best we could make it. If we could have agreed on how to make it better, then we would have made it better.”在C++這么一個混亂的領地，雖然STL并不完美，但對比起來說，他還是顯得那么地漂亮和精致辭。

后記

又到了關于C++文章結束的時候，我還是要老調重彈。C++這個世界是很復雜很危險的。單單本文章中的一個小小的string類就能引起這么多的討論，何況是別的類？

讓我們大膽地懷疑一下， C++是否真是一種高級的語言？目前的C++需要使用他的人有相當?shù)膶I(yè)技術水平，而寄希望于人的高水平看來是和技術的發(fā)展背道而馳的。好的一門開發(fā)語言是讓人可以容易方便地把更多的精力集中在業(yè)務邏輯性上。而C++這門語言卻需要技術人員比以住的C有著更為高深和專業(yè)的技術知識和能力。

是我們對string的“無知”搞亂了我們的程序，還是string這個類的設計把我們的程序搞亂了？是C++自己把軟件開發(fā)搞得一團混亂？還是使用C++的人把其搞得一團混亂？好像兼而有之，目前我們無法定論，但我們知道，無論是C++標準委員會，還是開發(fā)人員，大家的C++未來之路都還有很長。

(轉載時請注明作者和出處。未經(jīng)許可，請勿用于商業(yè)用途) 更多文章請訪問我的Blog: http://blog.csdn.net/haoel