std::string,std::vector,std::accumulate注意事项

Posted 2021-01-18 wangshaowei

　　在用string做字符串拼接时，会发现随着string的增大越来越慢，原因主要是string(和vector)是基于现行内存的数据结构，在海量数据时，经常会申请新的一块内存，把原有的数据拷贝过去然后再析构掉，这样非常浪费时间，使用reserve可以有效的改变这种情况

因为string(和vector)的reserve最大的用处是为了避免反复重新分配缓冲区内存而导致效率降低，或者在使用某些STL操作(例如std::copy)之前保证缓冲区够大。在面对大数据量时，应该先调用 reserve(size) 进行内存的预分配（这里 size 是预估的vector元素个数）

　　std::accumulate的用法

vector<string> vec = { "hello", " ", "world" };
    string s = accumulate(vec.begin(), vec.end(), s);

基本用法
先看一个使用accumulate的简单例子：

 

vector<int> vi{1, 2, 3};

cout << accumulate(vi.begin(), vi.end(), 0); // 6

这个例子中，accumulate接收了三个参数，一对迭代器用来标识开始和结束区间，第三个参数0，是accumulate操作的初始值. accumulate遍历[begin, end)这个区间，把每个值累加到0这个初始值上面，并最终返回累加结束的值(0 + 1 + 2 + 3) == 6.

通用用法
第一个例子只是accumulate特例的情况，其实它不仅仅能完成累加操作，它更一般的含义, 我觉得可以这样理解：

给定一个区间和初值init以及一个可选的操作函数op，返回一个和init一样类型的结果，该结果是通过对给定区间内的每个元素逐个累积用op操作作用于init而得到的。

另附如string 线性内存分配的缺陷

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）。