String類的設計一點都不容易，先不論C++，那怕是其他語言，在面對string的時候，一不小心也會掉坑，好比java，好比C#，一開始假設utf16是定長編碼，后來Unicode發展到兩個字節就裝不下一個碼位，字符串在java下，就有點尷尬了。就算是昧著良心用utf32編碼，碼元與碼位終于一一對應了，也會遇到物理字符與邏輯字符不對應的時候，好像有些語言的字符要用兩個unicode值來表示（很奇怪），有些語言的一個小寫字符對應著好幾個大寫字符。即便是字符串選定了一種編碼方式，始終還是要解決與其他編碼的交互問題，這些交互接口也不容易設計。另外，每次從長字符串中截取字符串都要重新new出來一條新的字符串，難免有一點點浪費，當然，現在計算機性能過剩，這純粹是強迫癥。
而到了c++下，設計字符串所遇到的問題，就遠比想象中復雜，無中生有的又憑空多出來很多不必要的要求，內存資源管理（這個在C++幾乎是無解），異常安全（往字符串添加新內容，假如內存分配失敗，必須保持原有值的完整性），還有性能要求（截取字符串避免生成新的字符串）。很多很多的要求，導致語言層面上壓根就沒法也不可能提供原生的字符串支持，而這一點上又引出來新的問題，代碼里面，邏輯意義上看，就不止存在一種字符串類型。好在，大C++擁有豐富多彩的feature，應該足以實現字符串類型了，這也是大C++的設計哲學，既然語言上沒法實現的東西，就提供用以支持這種東西的feature，用戶要怎么實現就怎么實現，選擇權交到用戶手里。
所以，C++的庫要怎么做出來一道string，這道菜的味道如何，就很讓人好奇。一路考察下來，讓人大跌眼鏡，竟然沒有一個c++庫能提供品質優良字符串， 其抽象充其量也就是比字符數組好一點點，完全就沒有Unicode編碼的抽象。Stl的字符串更讓人發指，竟然有幾個模板參數，本來多類型的字符串問題就更是雪上加霜了，另外stl的string還不能作為dll函數的參數類型。其實，很多時候，猿猴的要求真的不高，只要求一種utf8編碼的string，帶有格式化，還有一些split，trim，FindOneOf，toupper等常用字符串處理的操作就行了，只可惜，沒有一個c++庫能基本滿足這樣的基本要求。其實，這些要求，具體到C++下，要基本滿足，也的確很困難。
除了c++，很多語言的string類型都是原子屬性，一個string值，但凡一點風吹草動，都要生成新的string值，原有的值必須保持不變。此外，其官方也提供了類似于StringBuffer或者StringBuilder用以構造很長很長，以彌補這種動不動就生成新String的性能問題。這兩種類型涇渭分明。而c++的string，似乎是把這兩種類型糅合在一塊了，由此帶來語義上的不清晰，也造成很多不必要的麻煩，因為絕大多數場合下，只需要使用string的原子屬性，可變的string只是用來保存字符緩沖而已。知道嗎，stl的string有一百多個成員函數，很多都是不必要的重載，不過是為了避免字符串的復制而已。
所以，首先要對只讀的string做抽象，也即是string_view，只需兩個成員字段，字符串的起始地址以及緩沖長度，并且不要求以0結束，它有一個很好的特性，字符串的任何一部分，也都是字符串，甚至，必要時，一個字符，通過取地址，也可以看做是長度為1的string_view。任何連續的內存字符塊，都可以看做是string_view。其不必涉及內存的分配，顯得非常的輕量級，可以在程序中到處使用，只需注意到字符緩沖的生命周期，就不必擔心會引來什么問題。在string_view上，可以做trim，比較，查找，反向查找等操作，除了讀取單個字節的迭代器，還提供兩套迭代器，用以取到unicode碼位值（uin32），和用以訪問邏輯字符，其值也為stirng_view。
剩下來就是可寫可修改的string，要求以0結束，也即是stl的string，因為很多函數都在string_view上，所以這里基本上都只是插入、添加、刪除、替換的操作，要注意的是，中括號操作符不能返回字符引用，因為那樣完全沒有任何意義，就算是保留中括號返回字符值，意義也很小。Trim、查找、比較等操作，必須通過其成員函數view來返回代表自己的string_view。String的很多成員函數，大多數參數類型就是string_view，因此也沒有像是在stl下垃圾string的那么多亂七八糟的重載。很簡明的設計，性能與簡單的良好統一，不知為何，stl要到c++17的時候，才會加入stirng_view這么重要的類型，即便是如此，stl的string既有代碼已成定局，也沒辦法用string_view來簡化它的一百多個的成員函數了