C/C++字符串处理盘点:Char*/String/StringBuilder/TextPool/Rope

C/C++字符串处理盘点:Char*/String/StringBuilder/TextPool/Rope


许式伟
2008-3-20

概要

介绍StdExt的时候,我曾经提到,STL设计精良,但是以下几块仍然设计不足(或缺失):

关于内存管理,我们已经说得很多了。这里我们重点谈的是字符串处理/文本处理相关的问题。本篇是《字符串处理完整参考》这个系列的第一篇。

历史

字符串处理/文本处理是一个历史悠久,并且相当复杂的一个话题。从简单到字符串的比较(compare)连接(concat),到复杂的文本编辑、正则表达式、HTML文本内容的解析,都属于相关的范畴。

在C语言时代,C库提供了基于char*数据类型的字符串处理函数,典型代表如strlen,strcpy,strcat等。原始、容易出错,是这类字符串处理方法的典型特征。另外,strcat的效率并不高(Borland引入了strecpy来解决这个问题。其实这个strecpy的泛化版本,就是后来STL中的std::copy),而字符串查找(strstr)也是用了最原始的方式。

STL的string(basic_string)的出现,一定程度上改善了这种情况。至少C++程序员有一个使用界面“友善”的string(字符串)类了。然而,string类可以说是STL中最受争议的类(下文我们详细解释)。这些争议至少证明,STL的string类存在设计缺陷。

在SGI STL中,引入了rope类。这是一个重量级的字符串类。rope英文本意是绳子。string英文本意是线。所以rope是重量级的string,这个名字取得很形象,非常到位。

在StdExt库开始考虑字符串处理支持的时候,我引入了以下四个类:std::String / std::StringBuilder / std::TextPool / std::Rope。其中,std::String/std::StringBuilder其实是STL string类的功能分拆。std::String是一个常字符串,而std::StringBuilder负责字符串的修改操作。大家很清楚,String/StringBuilder的概念从Java中引入,我一直认为Java的字符串处理类的设计比C++这样把两者揉在一起的string实现要合理很多。std::TextPool / std::Rope则是字符串类的重量级实现,用来处理巨型的字符串。

STL的string(basic_string)的缺陷

归纳起来,STL的string类主要有以下这些争议点:

  • 接口过多且规格和其他STL容器没有达成很好的一致性。例如,string::find使用下标,而不是以iterator作为迭代位置,这和其他容器不太一样。
  • 内存碎片。由于过于频繁的字符串构造、析构,导致系统的内存碎片现象严重。
  • Copy-On-Write与多线程安全。string(basic_string)基于Copy-On-Write技术的原因,是因为 string的赋值被设计成为低开销的。但是一旦考虑到多线程安全问题,Copy-On-Write会把大量的时间花在锁的开销上。一些新的STL实现 (如SGI STL)放弃了基于Copy-On-Write的string实现。

盘点StdExt的字符串类:String/StringBuilder/TextPool/Rope

为什么我们需要这么多的字符串类?一个原因:字符串处理的应用环境很复杂,需要因地制宜,指望一个string类行遍天下是不可能的。

从支持的串的规模来讲,String/StringBuilder重点解决小字符串的问题(特别是StringBuilder,在大字符串情形下,一定会有性能瓶颈)。而TextPool, Rope重点解决巨型字符串的问题。

从实现上来讲,String/StringBuilder是线性内存的。而TextPool, Rope的字符串并不物理连续,它们是逻辑字符串。

从支持的操作来讲,String是常字符串;StringBuilder/TextPool主要支持改写(set)、添加(append)操作,但不推荐插入(insert)操作,从伸缩性来讲,TextPool好要好于StringBuilder;而Rope的操作侧重点在于优化字符串级的复杂操作,如取子字符串、插入、删除等,但是单个字符的修改和获取代价略高(相比于String/StringBuilder/TextPool)。

后文我们将展开来介绍这些组件。

你可能感兴趣的:(多线程,C++,c,正则表达式,C#)