C/C++字符串处理 (转)
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++字符串处理(2)：String - 常字符串
许式伟 2008-3-23概要
我们知道，C++标准库（STL）提供了string（basic_string）类进行字符串操作。字符串很可能除了内存分配器（allocator）1外使用最为频繁的STL类。但是C++社区对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实现。
我认同这些指责。字符串最好的设计，还是将string分拆为一个常字符串（std::String）和一个字符串操作类（StringBuilder）。我们的StdExt库这样做了。
理解String（BasicString）
StdExt的String（BasicString），和你以前见过的所有字符串类都不太一样。这个类比你想象的还要简单，它只有两个成员变量：
template <class_E> classBasicString{const_E* m_pszBuf; size_tm_length; };
它区别于string（basic_string）之处在于：
- 它是一个常字符串，它永远不会试图去篡改字符串内容（m_pszBuf指向的数据）。
- 它没有析构，你可以认为其实只是一个结构体。当然，为了方便，BasicString还是有构造函数。
- 它的m_pszBuf不以nil为结束。而是由m_length成员限定字符串的长度。
- 它不维护字符串内容（m_pszBuf）的生命周期。如上所述，它没有析构，任何时刻它只是接受或者生成字符串内容，但是不负责销毁它。
最后一点非常重要，也是它的特别之处：它并不维护字符串的生命周期。这可能让你诧异：居然会有这样字符串类，它并不管理字符串的生命周期。
但是我们这样做了。而这的确给我们带来很多便利。例如：
- 赋值（复制）、子串（substr）是非常轻量的操作。Copy-On-Write技术完全是多余的。
- 可以将任意的线性容器（如std::vector、std::basic_string）临时转换为String（非常轻量）。参见下文中对String::cast方法的介绍。
为什么String类可以不管理自己的生命周期？这就是我们StdExt的内存管理变革倡导的思想了。
浏览下String类的参考手册，你注意到有这样两个构造函数：
BasicString(constvalue_type* pszVal, size_typecch); template <classAllocT> BasicString(AllocT& alloc, constvalue_type* pszVal, size_typecch);
这表示：第一个构造函数传入的pszVal，其生命周期比BasicString长（到BasicString析构时仍然有效）。而第二个构造函数的意思是，pszVal是一个临时有效的字符串，这个构造函数将拷贝一个pszVal字符串的副本。
为什么不支持 BasicString(const value_type* pszVal) 这样的构造？
很简单，这个构造过于危险，我不能确定你的意图是什么。
关于TempString基类
从字面意思来讲，这是一个临时字符串类。为什么它会是String（即BasicString）的基类？这其实只是实现上的需要。TempString理论上就是String（只是有特殊的生命周期），和BasicString规格一致。之所以它最后成为BasicString的基类，完全是实现上方便的考虑。
以BasicString::compare为例，我们考察以下这个函数：
intBasicString::compare(constTempString<_E> b)const;
这个函数的含义非常丰富。相当于定义了以下这一系列的函数：
intBasicString::compare(const_E& b)const; // 与包含单个字符b的字符串比较intBasicString::compare(const_E* b)const; // 与C Style风格的字符串b比较intBasicString::compare(constbasic_string<_E>& b)const; // 与STL string比较intBasicString::compare(constBasicString<_E>& b)const; // 与另一个常String比较intBasicString::compare(constvector<_E>& b)const; // 与向量表示的字符串b比较intBasicString::compare(constBasicStringBuilder<_E>& b)const;
一个函数可抵6个函数！
你已经看到，BasicString中大量使用TempString来进行规格定义。这种方式的代码伸缩性无疑相当好。TempString的构造每增加一种线性字符串的支持，BasicString的所有相关操作即可立即支持该类型的字符串表示。
为了进一步说明这种做法的好处，我们再以字符串连接（concat）作为例子进行说明：
template <classAllocT, class_E> // 多个字符串连接。BasicString<_E> concat(AllocT& alloc, TempString<_E> a1, TempString<_E> a2, ...);
concat并非是BasicString类的成员函数。而是与BasicString有密切关系的全局函数。对于STL string类，你通常被推荐用operator+或者string::append函数来进行字符串连接。如：
std::stringa = std::string("Hello") + "" + "world" + "!!!";
而对应地，BasicString并无operator+或者append，它使用全局的std::concat函数进行字符串连接。如下：
std::Stringa = std::concat(alloc, "Hello", "", "world", "!!!");
有意思的是，这个std::concat不只可以高效地连接任意多的字符串，而且，它还可以连接高效地连接各种线性的字符串表示，包括：char*, std::string, std::vector<char>, std::String, std::StringBuilder等。例如：
std::stringhello = "Hello"; std::Stringspace("", 1); std::vector<char> excalmatory_mark(3, '!'); std::Stringa = std::concat(alloc, hello, space, "world", excalmatory_mark);
这其中的奥秘，全在TempString上。关于std::TempString的详细说明，参见TempString。
源码
StdExt库的工程主页：http://code.google.com/p/stdext/
参考阅读
C/C++字符串处理(4)：std::vector与std::StringBuilder
许式伟 2008-3-28
引子
std::StringBuilder 基于 std::vector 实现。所以尽管本文讨论 std::vector，但是所有的结论对 std::StringBuilder 同样有效。
实现概要
简单来讲，std::vector 是一个动态数组，管理的是一块线性的、可动态增长的内存。
如何加速 std::vector？
使用 vector::reserve
在大致可预估 vector 大小时，在插入数据前，应该先调用 reserve(size) 进行内存的预分配（这里 size 是预估的vector元素个数）。
避免在vector开始(begin)插入/删除数据
也就是说，应该尽量用 vector::insert(end(), …) 或者 vector::push_back/pop_back 添加/删除数据。而不要用 vector::insert(begin(), …) 操作。vector 没有提供 push_front 操作，原因只有一个：从 vector 开始处插入/删除数据是低效的做法。
如果你需要大量的在容器开始(begin)处 insert 数据，那么可以选择 std::deque（有 vector 随机访问的优点，也有 list 高效插入的优点）或者 std::list。
std::vector 的缺陷
什么时候不能用 std::vector ？
在容器需要容纳海量数据，并且元素个数不可预知时，坚决不能用 std::vector。所有基于线性内存的数据结构（如 std::vector，std::string）在海量数据时，遭遇性能瓶颈。
内存碎片
基于线性内存的数据结构（如 std::vector，std::string），还有一个典型的问题，就是容易产生内存碎片。在大量操作 std::vector 或 std::string 后，内存碎片就会比较严重。
std::vector 与 allocator
我们知道，std::vector 的原型是:
template <classDataT, classAllocT = std::allocator<DataT> > classvector;
那么是否需要像我们针对Map/MultiMap、Set/MultiSet、List/Slist、HashMap/HashMultiMap、HashSet/HashMultiSet、Deque 做的那样，将 AllocT 改用 GC Allocator呢？
答案是：不需要。GC Allocator 对于改善小内存分配是有益的。但是在动态的线性内存的数据结构无效。这样的数据结构除了 std::vector 外，典型的还有 std::string（std::basic_string）。
推荐阅读
- std::deque - 介于 std::vector 与 std::list 之间的一个数据结构，既可以随机定位，海量数据是性能仍然非常稳健（事实上其 push_back/push_front 的性能几乎为常数：O(1)，而不像 std::vector 那样，随着元素的增加，插入速度急剧下降）。
- std::list - 双向链表。
