提要
在先容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）。
后文我们将展开来先容这些组件。
