字符串是應(yīng)該作為內(nèi)置類型還是僅僅作為字符數(shù)組的一個(gè)別名呢？考慮到實(shí)現(xiàn)細(xì)節(jié)的可選性，我并不認(rèn)為需要對(duì)字符串進(jìn)行類型特化。在C++看來，字符串和“vector”容器基本上是一樣的，除了某些特殊操作，例如：大小寫轉(zhuǎn)換，需要依賴容器元素“char”類型（而不是作用于容器本身）。
字符串除了是一系列的字符組成，沒有什么特別的。更確切地說，程序中的字符串是特定字符集的字符集合。這里的字符并不總是圖象字符，它可以包含可打印字符，連接字符，或者控制字符，那么這又有什么不同嗎？
考慮計(jì)算字符串的長度，它應(yīng)該返回的是字符串中字形字符、連接符號(hào)的總數(shù)還是應(yīng)該返回字符串中字符占用空間的長度？兩個(gè)字面等價(jià)但是內(nèi)部存儲(chǔ)不同的的字符串應(yīng)該返回相同的長度嗎？考慮字符串規(guī)范化的復(fù)雜程度和應(yīng)用相同規(guī)則來計(jì)算‘length’長度聽起來很荒唐可笑。不同場景下字符串的長度很難統(tǒng)一計(jì)算，而且這還依賴于字符渲染引擎。唯一有意義的是返回字符串存儲(chǔ)空間大小——而這和計(jì)算字符數(shù)組的長度是一致的。
我們可以通過對(duì)字符串進(jìn)行索引和取下標(biāo)操作。那么我們應(yīng)該使用字符字面索引還是字符存儲(chǔ)索引？另外，考慮到組合Unicode字符串，沒有統(tǒng)一的標(biāo)準(zhǔn)來衡量哪些字符是字面顯示字符，哪些是控制字符。字符的組合種類很多（不受限制），因此沒有固定的字符類型來定義一個(gè)“邏輯”字符。因此字符串的操作應(yīng)該針對(duì)存儲(chǔ)字符地址——這又和字符數(shù)組沒有區(qū)別了。
C++中的string和vector只有一個(gè)明顯的區(qū)別是：string是以null結(jié)尾的。并且string提供c_str方法返回內(nèi)部字符串存儲(chǔ)指針。（C++11定義了string來表明這是存儲(chǔ)字符串的有效方式）。
對(duì)C++來說，如果string不提供c_str方法，那么string類就基本沒有存在的必要（相對(duì)于vector）。然而，這是也不是一個(gè)必須的特性，提供出來只是為了方便將string進(jìn)行轉(zhuǎn)換，從而方便調(diào)用早期C風(fēng)格的字符串指針API。怪異的是，C++標(biāo)準(zhǔn)庫也使用了類似的接口，ofstream的構(gòu)造函數(shù)需要傳遞的是一個(gè)‘const char*’指針而不是string類型。（在C++11中修復(fù)了該問題）
使用null作為字符串結(jié)束符也是一個(gè)糟糕的選擇，導(dǎo)致在C函數(shù)庫中，一些函數(shù)如：strcat, strcpy并不安全。使用C風(fēng)格的字符串是一件令人生畏且容易出錯(cuò)的差事?，F(xiàn)代風(fēng)格的API接口已經(jīng)很少依賴使用null作為字符串結(jié)束，這些函數(shù)通常都要求提供字符串的長度作為一個(gè)參數(shù)。
導(dǎo)致C++中的string和vector有所不同，這是因?yàn)闅v史包袱，而大多數(shù)程序員都不需要關(guān)心它的存在。
前述的討論基于這樣一個(gè)假設(shè)：字符串存儲(chǔ)中一個(gè)存儲(chǔ)元素編碼一個(gè)字符。而通常采用這種編碼方式是效率低下的，使用變長字符編碼可以解決這個(gè)問題：使用不同數(shù)量的字節(jié)來表示一個(gè)字符。例如：在UTF-16中，一個(gè)字符可以由2個(gè)字節(jié)或者4個(gè)字節(jié)進(jìn)行存儲(chǔ)。而不存儲(chǔ)字符的單元作為存儲(chǔ)序列的一部分，被叫做字符代理。
字符代理和連接字符不同。字符代理在字符集中沒有意義：它只是用來填充編碼占位。對(duì)字符的到操作依賴以實(shí)際存儲(chǔ)元素位置。將編碼字符串當(dāng)作一系列的字符來操作，通常很麻煩而且容易導(dǎo)致未知語義。編碼字符串的length應(yīng)該返回什么值呢？是編碼字符的個(gè)數(shù)還是存儲(chǔ)元素的個(gè)數(shù)？
目前的方法是，將編碼字符串作為一種特殊字符類型，并提供一定程度的抽象，你可要存儲(chǔ)各種類型的字符，也可以將其作為一個(gè)字符序列操作。length返回字符的個(gè)數(shù)，而與底層編碼方式無關(guān)（或者通過其他方法返回）。
設(shè)計(jì)這個(gè)類的挑戰(zhàn)在于效率?；静僮魅缢饕址兂闪艘粋€(gè)線性復(fù)雜度操作。需要先對(duì)字符串進(jìn)行解碼，從開始掃描，重新組織字符代理，并計(jì)算真實(shí)的字符個(gè)數(shù)。即便是簡單的前向掃描也依賴以循環(huán)和下一個(gè)字符狀態(tài)的解析。而這種操作負(fù)載在所有的基本操作都會(huì)被累積，比如拆分，翻譯和正則表達(dá)式匹配。
目前（內(nèi)置字符串類型）的語言并沒有按這種方式操作字符串，考慮效率問題，這使得采用這種方式變得沒有吸引力。而在字符域，加載字符，解碼字符和對(duì)字符串進(jìn)行處理則簡單得多。這種方式會(huì)消耗更多內(nèi)存，但是我認(rèn)為這對(duì)于世界上現(xiàn)有的字符集來說并不是一個(gè)主要問題——盡管存在大量的字符集，但是相較其他集合則小得多。
字符串有許多相對(duì)于簡單數(shù)組的特殊操作：規(guī)范化、字符轉(zhuǎn)換、正則表達(dá)式運(yùn)算、字符解析、格式化、裁剪、編碼等等。相對(duì)地，任何類型的“vector”都有一些特殊操作：數(shù)字可以累加，求平均，計(jì)算中位數(shù)。向量可以做變換，簡化和柵格化。
值得探討的是，一些集合運(yùn)算是應(yīng)該作為一個(gè)成員函數(shù)還是獨(dú)立函數(shù)。如果上述操作作為一個(gè)成員函數(shù)，那么需要特地提供一個(gè)”string”類型。而上述操作提供為獨(dú)立函數(shù)的話，使用原始”array”數(shù)組類型就可以工作了。顯然，上述操作都可以寫成獨(dú)立函數(shù)，沒有那個(gè)函數(shù)需要特別的處理，只需要提供array接口就可以了。
不過有一個(gè)語法上的特例，如果我把”str.toUpperCase()”提取為獨(dú)立函數(shù)顯得有點(diǎn)怪異。D語言則完全統(tǒng)一了函數(shù)調(diào)用語法。我預(yù)計(jì)C++也會(huì)跟隨這一趨勢，許多操作函數(shù)已經(jīng)被當(dāng)作獨(dú)立函數(shù)提供而不是采用成員函數(shù)。似乎發(fā)展也傾向于獨(dú)立函數(shù)。
如果獨(dú)立函數(shù)可行，那么就沒有必要提取一個(gè)string類。字符串操作可以寫成作用于字符數(shù)組的獨(dú)立函數(shù)。
如果你的字符串不僅僅使用ASCI字符，通?？梢钥紤]使用Unicode字符集，但是，也有可能在你的代碼中，只使用了ascii碼或者是latin-1編碼。不過大多數(shù)字符串都不會(huì)僅限于此。有些語言，比如PHP，允許你在全局范圍設(shè)定編碼方式。使用string做標(biāo)記，通常都不會(huì)做太多變化（譯：我猜測作者的意思應(yīng)該是大多數(shù)語言已經(jīng)內(nèi)置了string的編碼方式，而且不允許調(diào)整）。
我們假定字符集使用ascii編碼，以ascii編碼的字符串使用一個(gè)模版類string。為了標(biāo)識(shí)不同于其他字符集，我們把這個(gè)字符串類型標(biāo)識(shí)為“char ascii”。一旦我們做了這樣的設(shè)定，我們就不希望再感受到string的類型了，它工作起來就和數(shù)組很相似了。
回到剛才談到的變長編碼：如果你使用UTF-16編碼字符，并且需要使用字符代理?，F(xiàn)在string變得含義模糊了，string應(yīng)該被當(dāng)做unicode字符組合還是真實(shí)的utf16編碼值？（沿用剛才的實(shí)現(xiàn)）使用一個(gè)類型別名標(biāo)識(shí)比較合適，我們假定為“type utf16:binary 16bit”，并作為一個(gè)數(shù)組。現(xiàn)在歧義消除了，字符串是編碼值的集合，而不是字符。
現(xiàn)在我覺得不需要定義一個(gè)特殊的string類型，如果需要string類型，可以僅僅使用一個(gè)數(shù)組的別名。但是string作為基礎(chǔ)類型被大量使用，這也導(dǎo)致了許多問題。一些情況下需要著重考慮字符編碼，使用特定類型的數(shù)組就會(huì)比較安全。同時(shí)也需要一個(gè)富字符串處理函數(shù)庫，但是不應(yīng)該作為一個(gè)字符串類型（string）提供。
你能舉例有什么情況下需要專門的string類型，或者這樣做會(huì)更有效嗎？
聯(lián)系客服
