近兩年來(lái)在寫(xiě)C++的運(yùn)行時(shí)環(huán)境，反射、運(yùn)行時(shí)類型信息、內(nèi)存管理、并行、字符串、協(xié)程、ORM等等，基本上重寫(xiě)了一套標(biāo)準(zhǔn)庫(kù)以及運(yùn)行庫(kù)。對(duì)于在c++下使用字符串，深有體會(huì)。一開(kāi)始嘔心瀝血，殫精竭慮，支持多種編碼方式（Utf8、Utf7、GB2312、Utf16LE，Utf16BE等）的字符串類型，以及在此之上的對(duì)這些字符串提供格式化、字符串解析、json、xml、文件讀寫(xiě)BOM等等功能，必須承認(rèn)，大C++真是變態(tài)，像是這樣變態(tài)無(wú)聊的概念都可以支持，還可以實(shí)現(xiàn)得很好，用起來(lái)確實(shí)也方便?？墒牵看蚊媾R字符串操作的時(shí)候，都會(huì)心里發(fā)毛，都會(huì)嘀咕此時(shí)此刻，糾結(jié)的是哪門(mén)子的編碼，也搞得很多代碼必須以template的形式，放在頭文件上，不放在頭文件，就必須抽象出來(lái)一個(gè)通用的動(dòng)態(tài)字符串類型，代表任意編碼的一種字符串類型，代碼里面引入各種各樣臆造的復(fù)雜性。終于受不了啦，最后搞成統(tǒng)一用utf8編碼，重構(gòu)了幾千行代碼（十幾個(gè)文件），然后，整個(gè)字符串世界終于清靜了，接口api設(shè)計(jì)什么的，也一下子清爽了很多。整個(gè)程序內(nèi)部，就應(yīng)該只使用同一種編碼的字符串。stl的帶有多個(gè)模板的string設(shè)計(jì)，就是無(wú)病呻吟，畫(huà)蛇添足。
為什么選擇Utf8編碼，首先，非unicode編碼的字符串是不能考慮的；其次，utf16也是變長(zhǎng)的編碼方式，而且還有大小端的區(qū)別，所以也不能考慮；utf32又太占用內(nèi)存了。想來(lái)想去，終于下定決心，utf8簡(jiǎn)直就是唯一的選擇了。雖然可能有這樣那樣的小問(wèn)題，比如說(shuō)，純中文文本，utf8占用多50%內(nèi)存（相比于Utf16），windows下utf8有點(diǎn)不友好。但其實(shí)都不是問(wèn)題，也都可以解決。比如說(shuō)，windows下，所有的涉及字符串與系統(tǒng)的api交互，先臨時(shí)轉(zhuǎn)換成utf16，然后再調(diào)用api。api的返回結(jié)果為utf16，再轉(zhuǎn)換為utf8。好像有一點(diǎn)性能上的損失，其實(shí)沒(méi)啥大不了的。windows對(duì)于多字節(jié)也是這樣支持的，完全就感受不到性能上的影響。總之，utf8簡(jiǎn)直就是程序處理的唯一字符串編碼。
吐槽一下std的字符串，以及與此相關(guān)的一切概念，iostream，locale等等東西，垃圾設(shè)計(jì)的典范。接口不友好，功能弱，而且還性能差，更關(guān)鍵的是其抽象上的泄漏。一整天就只會(huì)在引用計(jì)數(shù)，寫(xiě)時(shí)復(fù)制，短字符串優(yōu)化上做文章，時(shí)間精力都不用在刀刃上。C++17終于引入string_view的類型，情況稍微有些改善。由于字符串使用上不方便，也因此損失了一大片的用戶，陣地一再失守。整體上講，stl的設(shè)計(jì)，自然是有精心的考慮，但是，作出這些抽象的標(biāo)準(zhǔn)會(huì)上一大群的老爺子們，大概率上講，應(yīng)該是沒(méi)有用stl正兒八經(jīng)地開(kāi)發(fā)工業(yè)級(jí)上的代碼，臆造抽象，顧慮太多，表面上看起來(lái)好像是那么一回事，真正用起來(lái)的時(shí)候，就不太對(duì)勁，會(huì)有這樣那樣的不足，很不方便。
簡(jiǎn)單說(shuō)一下U8String的設(shè)計(jì)思路。U8String用以管理字符串編碼緩存的生命周期，追加縮短替換字符串，支持通過(guò)下標(biāo)可以讀取字節(jié)char，但是不支持將字節(jié)寫(xiě)入到某個(gè)索引上的位置，當(dāng)然支持往字符串中插入unicode編碼的字符。至于字符串的比較、查找、Trim、截取子字符串這些常用操作，就全部壓在U8View上。如果U8String要使用這些，要先通過(guò)view的函數(shù)，獲取自己字節(jié)緩存下的視圖。U8View表示一段連續(xù)的字符編碼內(nèi)存，U8View的任意一部分也是U8View，不要求以0結(jié)束。只要求U8View的生存周期不能比其宿主（U8String，字符數(shù)組，U8原生字符串）長(zhǎng)命。事實(shí)上，很多api的字符串參數(shù)，其實(shí)只是要求為U8View就行了，不需要是什么const string&類型。此外，還提供U8PointPtr的指針類型，用以遍歷U8View，其取值為unicode編碼值，也就是wchar_t類型。另外，既然有U8View，自然也就有ArrayView，代表連續(xù)內(nèi)存塊的任意類型。
自然，庫(kù)中必須提供格式化Fmt以及解析字符串Scanf的函數(shù)。StrFmt用以生成新的U8String，而Fmt格式化函數(shù)中傳入字符串的話，就將格式化結(jié)果追加到字符串后面。Fmt可以格式化數(shù)據(jù)到控制臺(tái)，文本文件，日志等等輸出結(jié)果上。StrFmt的實(shí)現(xiàn)只是簡(jiǎn)單地調(diào)用Fmt并返回U8String。有了Fmt和Scanf，操作字符串就很方便很靈活了，同時(shí)也消除很多很多有關(guān)字符串相關(guān)的處理函數(shù)。Fmt不僅僅能格式化基本類型，自定義類型，還能格式化數(shù)組，vector，list，pair，tuple等模板類型的數(shù)據(jù)。庫(kù)中也提供了類似于iostream重載<<和>>的操作符。大C++提高的feature，造出來(lái)的string類型，使用上的方便，一點(diǎn)都不遜色于其他任何語(yǔ)言的原生string類型。當(dāng)然，std的那個(gè)string，簡(jiǎn)直就是廢物。
不管怎么說(shuō)，本人還是很喜歡C++的，用c++寫(xiě)代碼很舒暢，可比用C#、haskell、lisp、scala時(shí)要開(kāi)心很多。C++發(fā)展到C++11，基本功能也都完備了，當(dāng)然，C++14、C++17自然功能更加強(qiáng)大，特別是實(shí)現(xiàn)模板庫(kù)的時(shí)候，就更方便了，也確實(shí)很吸引人。自然，C++也非十全十美，也有很多的不足，比如不能自定義操作符，不提供非侵入式的成員函數(shù)，缺乏延遲求值的語(yǔ)言機(jī)制，引用的修改綁定（只要不綁定到nullptr就好了），成員函數(shù)指針的無(wú)端限制。但是，世界上又哪里存在完美的language呢，特別是對(duì)于這種直接操縱內(nèi)存的底層語(yǔ)言來(lái)說(shuō)。至于rust，叫囂著要取代c++，就它那副特性，還遠(yuǎn)著呢。