概要

　　在介绍StdExt的时候，我曾经提到，STL设计精良，但是以下几块仍然设计不足（或缺失）：

　　allocator（内存管理）

　　string（字符串处理/文本处理）

　　parallel programming（并行编程）

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

　　历史

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

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