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

许式伟
2008-3-20

历史

字符串处理/文本处理是一个历史悠久，并且相当复杂的一个话题。从简单到字符串的比较（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）。

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

看了你的BasicString的接口，我的感觉是借鉴了Java和C#的immutable的设计。和std::basic_string相比，我有下面一些建议： 1.去掉了几乎所有的in-place editing的操作，这很好。但是，clear和erase仍然存在，违背了immutable。个人认为唯一需要存在的就是swap，swap在这里是为了保证效率和异常安全。 2.所有的字符串算法都应该变成全局函数而不是成员函数。全局化以后可以减小BasicString的核心接口，全局函数可以依靠核心接口来实现。况且，考虑到编译器优化，也几乎不会导致性能损失。这样，就open for extension了.用户/库作者可以自由扩展算法而不必修改类设计，甚至为某些算法提供不同的实现。 同样的理由，那个trace函数让人很是不舒服。 3.倾向于对应的ctor而不是attach函数。 4.对于basic_string来说，理论上data和c_str还是有细微的差别的。只有c_str是保证'/0'结尾的。如果要和stl保持一致，似乎提供c_str更好。 5.同义词问题。比如size和length.我认为，对于同义词，只能有一个出现在成员函数中，这样保持接口最小化。其他的同义词则可以变成inline的全局函数。 6.strSTL这种转换函数还是全局为好，这可以避免你的BasicalString依赖basic_string. 同样的理由，其他的cast也以全局函数的形式在必要的地方出现，而不是在类中导致接口膨胀。 个人观点，仅供参考。 对Allocator的处理确实让我很受启发，但是个人认为，丧失不少灵活性。对于字符串这样一个非常基础的类型来说，丧失灵活性恐怕是很难被广泛运用的。我觉得像basic_string那样，提供额外的模板参数来指定allocator适应性更好一些。

to wingfiring: 感谢你的建议。以下是我的一些考虑： 1. 关于immutable。BasicString与mutable相关的操作主要有：attach, assign, clear/erase。其实它们可以没有，全部以ctor提供是可能的。例如 a.clear() 等价于 a = std::String()。但是基于以下原因，我还是引入了这些函数： 1) 与basic_string的规格尽量一致。毕竟C++程序员已经习惯于使用basic_string。 2) ctor导致含糊的语义。我个人非常不喜欢一种方便但不清晰的函数规格。这也是我不提供BasicString(const _E* psz);这个构造函数的原因（尽管这个构造会带来方便）。但是我提供了BasicString::attach(const _E* psz)，因为后者有明确的语义。 3) 其实attach, assign, clear/erase只是表示BasicString是mutable的。但是，实际上字符串的内存仍然是immutable的。故此实际上这些函数并不违背immutable的设计原则。 2. 关于规格的最小化。 我很认同你的观念。类应该只提供最小的、必不可少的操作集合。但是还是基于兼容basic_string的原则，我还是选择了目前的做法。 3. data/c_str 是的，data()函数并不确保一定以nil做结尾，故此我们提供了该函数。而c_str()被strSTL()代替。为什么会有strSTL()？其实我也不喜欢，但是既然basic_string是标准库，我还是得尽量提供一些桥接方法。如果basic_string不是STL的，我会将桥接代码改为全局函数。 4. allocator 如果你仔细去了解了GC Allocator，就会发现，GC Allocator（不是allocator）作为BasicString的模板参数并不值得，相反会失去灵活性。   原稿连接:http://blog.csdn.net/xushiweizh/archive/2008/03/20/2201181.aspx