• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            huaxiazhihuo

             

            string類的設(shè)計

            String類的設(shè)計一點都不容易,先不論C++,那怕是其他語言,在面對string的時候,一不小心也會掉坑,好比java,好比C#,一開始假設(shè)utf16是定長編碼,后來Unicode發(fā)展到兩個字節(jié)就裝不下一個碼位,字符串在java下,就有點尷尬了。就算是昧著良心用utf32編碼,碼元與碼位終于一一對應(yīng)了,也會遇到物理字符與邏輯字符不對應(yīng)的時候,好像有些語言的字符要用兩個unicode值來表示(很奇怪),有些語言的一個小寫字符對應(yīng)著好幾個大寫字符。即便是字符串選定了一種編碼方式,始終還是要解決與其他編碼的交互問題,這些交互接口也不容易設(shè)計。另外,每次從長字符串中截取字符串都要重新new出來一條新的字符串,難免有一點點浪費,當(dāng)然,現(xiàn)在計算機性能過剩,這純粹是強迫癥。

            而到了c++下,設(shè)計字符串所遇到的問題,就遠(yuǎn)比想象中復(fù)雜,無中生有的又憑空多出來很多不必要的要求,內(nèi)存資源管理(這個在C++幾乎是無解),異常安全(往字符串添加新內(nèi)容,假如內(nèi)存分配失敗,必須保持原有值的完整性),還有性能要求(截取字符串避免生成新的字符串)。很多很多的要求,導(dǎo)致語言層面上壓根就沒法也不可能提供原生的字符串支持,而這一點上又引出來新的問題,代碼里面,邏輯意義上看,就不止存在一種字符串類型。好在,大C++擁有豐富多彩的feature,應(yīng)該足以實現(xiàn)字符串類型了,這也是大C++的設(shè)計哲學(xué),既然語言上沒法實現(xiàn)的東西,就提供用以支持這種東西的feature,用戶要怎么實現(xiàn)就怎么實現(xiàn),選擇權(quán)交到用戶手里。

            所以,C++的庫要怎么做出來一道string,這道菜的味道如何,就很讓人好奇。一路考察下來,讓人大跌眼鏡,竟然沒有一個c++庫能提供品質(zhì)優(yōu)良字符串, 其抽象充其量也就是比字符數(shù)組好一點點,完全就沒有Unicode編碼的抽象。Stl的字符串更讓人發(fā)指,竟然有幾個模板參數(shù),本來多類型的字符串問題就更是雪上加霜了,另外stlstring還不能作為dll函數(shù)的參數(shù)類型。其實,很多時候,猿猴的要求真的不高,只要求一種utf8編碼的string,帶有格式化,還有一些splittrimFindOneOftoupper等常用字符串處理的操作就行了,只可惜,沒有一個c++庫能基本滿足這樣的基本要求。其實,這些要求,具體到C++下,要基本滿足,也的確很困難。

            除了c++,很多語言的string類型都是原子屬性,一個string值,但凡一點風(fēng)吹草動,都要生成新的string值,原有的值必須保持不變。此外,其官方也提供了類似于StringBuffer或者StringBuilder用以構(gòu)造很長很長,以彌補這種動不動就生成新String的性能問題。這兩種類型涇渭分明。而c++string,似乎是把這兩種類型糅合在一塊了,由此帶來語義上的不清晰,也造成很多不必要的麻煩,因為絕大多數(shù)場合下,只需要使用string的原子屬性,可變的string只是用來保存字符緩沖而已。知道嗎,stlstring有一百多個成員函數(shù),很多都是不必要的重載,不過是為了避免字符串的復(fù)制而已。

            所以,首先要對只讀的string做抽象,也即是string_view,只需兩個成員字段,字符串的起始地址以及緩沖長度,并且不要求以0結(jié)束,它有一個很好的特性,字符串的任何一部分,也都是字符串,甚至,必要時,一個字符,通過取地址,也可以看做是長度為1string_view。任何連續(xù)的內(nèi)存字符塊,都可以看做是string_view。其不必涉及內(nèi)存的分配,顯得非常的輕量級,可以在程序中到處使用,只需注意到字符緩沖的生命周期,就不必?fù)?dān)心會引來什么問題。在string_view上,可以做trim,比較,查找,反向查找等操作,除了讀取單個字節(jié)的迭代器,還提供兩套迭代器,用以取到unicode碼位值(uin32),和用以訪問邏輯字符,其值也為stirng_view

            剩下來就是可寫可修改的string,要求以0結(jié)束,也即是stlstring,因為很多函數(shù)都在string_view上,所以這里基本上都只是插入、添加、刪除、替換的操作,要注意的是,中括號操作符不能返回字符引用,因為那樣完全沒有任何意義,就算是保留中括號返回字符值,意義也很小。Trim、查找、比較等操作,必須通過其成員函數(shù)view來返回代表自己的string_viewString的很多成員函數(shù),大多數(shù)參數(shù)類型就是string_view,因此也沒有像是在stl下垃圾string的那么多亂七八糟的重載。很簡明的設(shè)計,性能與簡單的良好統(tǒng)一,不知為何,stl要到c++17的時候,才會加入stirng_view這么重要的類型,即便是如此,stlstring既有代碼已成定局,也沒辦法用string_view來簡化它的一百多個的成員函數(shù)了

            posted on 2018-05-26 11:51 華夏之火 閱讀(1409) 評論(0)  編輯 收藏 引用 所屬分類: c++技術(shù)探討

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品国产WWW456C0M| 国产精品免费久久久久影院 | 久久精品国产清自在天天线| 久久综合狠狠色综合伊人| 国产高潮国产高潮久久久91| 久久久WWW免费人成精品| 亚洲精品无码久久久久| 国产巨作麻豆欧美亚洲综合久久| 久久亚洲中文字幕精品一区| 国产精品视频久久久| 无码人妻久久一区二区三区蜜桃| 97久久国产亚洲精品超碰热| 久久国产精品视频| 青青草原综合久久大伊人精品| 人人狠狠综合久久亚洲| 久久综合久久综合久久| 亚洲精品无码久久久久去q | 久久激情五月丁香伊人| 久久久久精品国产亚洲AV无码| 久久亚洲欧洲国产综合| 国产一级持黄大片99久久| 精品久久久久中文字幕日本| 久久精品国产久精国产思思| 久久精品天天中文字幕人妻 | 亚洲国产精品久久电影欧美| 国产成人久久久精品二区三区| 久久久久久国产精品无码超碰| 久久成人小视频| 色妞色综合久久夜夜| 久久天天躁狠狠躁夜夜av浪潮| 久久国产精品-国产精品| 国产V综合V亚洲欧美久久| 久久99精品久久久大学生| 久久乐国产综合亚洲精品| 久久久无码精品亚洲日韩蜜臀浪潮 | 婷婷综合久久中文字幕| 中文字幕亚洲综合久久| 99久久国产综合精品成人影院| 99久久777色| 国产午夜电影久久| 国产精品成人精品久久久|