huaxiazhihuo

 

U8String的重构体会

近两年来在写C++的运行时环境,反射、运行时类型信息、内存管理、并行、字符串、协程、ORM等等,基本上重写了一套标准库以及运行库。对于在c++下使用字符串,深有体会。一开始呕心沥血,殚精竭虑,支持多种编码方式(Utf8Utf7GB2312Utf16LEUtf16BE等)的字符串类型,以及在此之上的对这些字符串提供格式化、字符串解析、jsonxml、文件读写BOM等等功能,必须承认,大C++真是变态,像是这样变态无聊的概念都可以支持,还可以实现得很好,用起来确实也方便。可是,每次面临字符串操作的时候,都会心里发毛,都会嘀咕此时此刻,纠结的是哪门子的编码,也搞得很多代码必须以template的形式,放在头文件上,不放在头文件,就必须抽象出来一个通用的动态字符串类型,代表任意编码的一种字符串类型,代码里面引入各种各样臆造的复杂性。终于受不了啦,最后搞成统一用utf8编码,重构了几千行代码(十几个文件),然后,整个字符串世界终于清静了,接口api设计什么的,也一下子清爽了很多。整个程序内部,就应该只使用同一种编码的字符串。stl的带有多个模板的string设计,就是无病呻吟,画蛇添足。

为什么选择Utf8编码,首先,非unicode编码的字符串是不能考虑的;其次,utf16也是变长的编码方式,而且还有大小端的区别,所以也不能考虑;utf32又太占用内存了。想来想去,终于下定决心,utf8简直就是唯一的选择了。虽然可能有这样那样的小问题,比如说,纯中文文本,utf8占用多50%内存(相比于Utf16),windowsutf8有点不友好。但其实都不是问题,也都可以解决。比如说,windows下,所有的涉及字符串与系统的api交互,先临时转换成utf16,然后再调用apiapi的返回结果为utf16,再转换为utf8。好像有一点性能上的损失,其实没啥大不了的。windows对于多字节也是这样支持的,完全就感受不到性能上的影响。总之,utf8简直就是程序处理的唯一字符串编码。

吐槽一下std的字符串,以及与此相关的一切概念,iostreamlocale等等东西,垃圾设计的典范。接口不友好,功能弱,而且还性能差,更关键的是其抽象上的泄漏。一整天就只会在引用计数,写时复制,短字符串优化上做文章,时间精力都不用在刀刃上。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。有了FmtScanf,操作字符串就很方便很灵活了,同时也消除很多很多有关字符串相关的处理函数。Fmt不仅仅能格式化基本类型,自定义类型,还能格式化数组,vectorlistpairtuple等模板类型的数据。库中也提供了类似于iostream重载<<>>的操作符。大C++提高的feature,造出来的string类型,使用上的方便,一点都不逊色于其他任何语言的原生string类型。当然,std的那个string,简直就是废物。

不管怎么说,本人还是很喜欢C++的,用c++写代码很舒畅,可比用C#haskelllispscala时要开心很多。C++发展到C++11,基本功能也都完备了,当然,C++14C++17自然功能更加强大,特别是实现模板库的时候,就更方便了,也确实很吸引人。自然,C++也非十全十美,也有很多的不足,比如不能自定义操作符,不提供非侵入式的成员函数,缺乏延迟求值的语言机制,引用的修改绑定(只要不绑定到nullptr就好了),成员函数指针的无端限制。但是,世界上又哪里存在完美的language呢,特别是对于这种直接操纵内存的底层语言来说。至于rust,叫嚣着要取代c++,就它那副特性,还远着呢。

posted on 2018-05-22 17:10 华夏之火 阅读(1682) 评论(0)  编辑 收藏 引用 所属分类: c++技术探讨


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(6)

随笔分类

随笔档案

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜