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