C/C++字符串处理

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


许式伟
2008-3-20

概要

在介绍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)。

 

C/C++字符串处理(2):String - 常字符串


许式伟
2008-3-23

Table of Contents
概要
理解String(BasicString)
关于TempString基类
源码
参考阅读

概要

我们知道,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>
class BasicString
{
const _E* m_pszBuf;
size_t m_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(const value_type* pszVal, size_type cch);

template <class AllocT>
BasicString(AllocT& alloc, const value_type* pszVal, size_type cch);

这表示:第一个构造函数传入的pszVal,其生命周期比BasicString长(到BasicString析构时仍然有效)。而第二个构造函数的意思是,pszVal是一个临时有效的字符串,这个构造函数将拷贝一个pszVal字符串的副本。

为什么不支持 BasicString(const value_type* pszVal) 这样的构造?

很简单,这个构造过于危险,我不能确定你的意图是什么。

关于TempString基类

从字面意思来讲,这是一个临时字符串类。为什么它会是String(即BasicString)的基类?这其实只是实现上的需要。TempString理论上就是String(只是有特殊的生命周期),和BasicString规格一致。之所以它最后成为BasicString的基类,完全是实现上方便的考虑。

以BasicString::compare为例,我们考察以下这个函数:

int BasicString::compare(const TempString<_E> b) const; 

这个函数的含义非常丰富。相当于定义了以下这一系列的函数:

int BasicString::compare(const _E& b) const; // 与包含单个字符b的字符串比较
int BasicString::compare(const _E* b) const; // 与C Style风格的字符串b比较
int BasicString::compare(const basic_string<_E>& b) const; // 与STL string比较
int BasicString::compare(const BasicString<_E>& b) const; // 与另一个常String比较
int BasicString::compare(const vector<_E>& b) const; // 与向量表示的字符串b比较
int BasicString::compare(const BasicStringBuilder<_E>& b) const;

一个函数可抵6个函数!

你已经看到,BasicString中大量使用TempString来进行规格定义。这种方式的代码伸缩性无疑相当好。TempString的构造每增加一种线性字符串的支持,BasicString的所有相关操作即可立即支持该类型的字符串表示。

为了进一步说明这种做法的好处,我们再以字符串连接(concat)作为例子进行说明:

template <class AllocT, class _E> // 多个字符串连接。
BasicString<_E> concat(AllocT& alloc, TempString<_E> a1, TempString<_E> a2, ...);

concat并非是BasicString类的成员函数。而是与BasicString有密切关系的全局函数。对于STL string类,你通常被推荐用operator+或者string::append函数来进行字符串连接。如:

std::string a = std::string("Hello") + " " + "world" + "!!!"; 

而对应地,BasicString并无operator+或者append,它使用全局的std::concat函数进行字符串连接。如下:

std::String a = std::concat(alloc, "Hello", " ", "world", "!!!"); 

有意思的是,这个std::concat不只可以高效地连接任意多的字符串,而且,它还可以连接高效地连接各种线性的字符串表示,包括:char*, std::string, std::vector<char>, std::String, std::StringBuilder等。例如:

std::string hello = "Hello";
std::String space(" ", 1);
std::vector<char> excalmatory_mark(3, '!');
std::String a = std::concat(alloc, hello, space, "world", excalmatory_mark);

这其中的奥秘,全在TempString上。关于std::TempString的详细说明,参见TempString。

源码

  • stdext/text/TempString.h
  • stdext/text/BasicString.h

StdExt库的工程主页:http://code.google.com/p/stdext/

参考阅读

  • String
  • TempString
  • concat
  • std::string

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 <class DataT, class AllocT = std::allocator<DataT> >
class vector;

那么是否需要像我们针对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 - 双向链表。

 

你可能感兴趣的:(数据结构,vector,String,basic,iterator,Class)