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