STL中的隐性性能开销与副作用

1 隐性性能开销

1.1 STL容器的clear的时间复杂度不是O(1)

很多人潜意识认为STL容器中clear()成员函数的时间复杂度为常量时间复杂度O(1)。原因是大家觉得对于vector而言，clear()之后，修改了size()的结果，不影响capacity()的结果，因而得出clear()只是修改了某个标记，从而得出clear()为常量时间复杂度的错误结论。

实际上c++标志明确指出不管是序列容器还是关联容器，其clear()成员函数读书线性时间复杂度O(n)。因为只要执行了clear()就需要对其存储的元素调用析构函数，这个析构操作显然是逐个进行的。

当然在事件中，也有个例。比如当vector存储基本数据类型或POD类型（如：基本数据类型构成struct的时候），由于其元素类型没有析构函数，加之vector内部连续存储的特性，编译器的实现是可以在常量时间完成clear()的。

当然仅限于vector存储基本数据类型和POD类型的时候，编译器可能有此优化。如果vector存储的是其他类型的对象，或者是其他容器（list、map、unordered_map）都是没办法做这个优化的。

1.2 auto 替代手写类型

 在基于范围的循环中尽量使用auto&，否则容易踩坑。这个观点在Scott Meryer的《Effictive Modern C++》一书中条款5已经讲得很清楚了。

比如在unordered_map而言，其中的元素类型为：

std::pair<const std::string, int>

 如果这样遍历：

std::unordered_map<std::string, int> m;
for (const std::pair<std::string, int>& p: m) {
    ... 
}

你以为有const就对了么？实则不然。这里会触发pair<const std::string, int>类型的原始对象构造一个pair<const std::string, int>的临时对象。有额外的拷贝构造开销，并且这里的引用还是引用的临时对象。

但如果你使用auto&则不会出问题。编译器自动的类型识别会帮你处理好。

std::unordered_map<std::string, int> m;
for (auto& p: m) {
    ... 
}

1.3减少隐性的重复操作

从map中查找某个key对应的value。一般情况下：

// dict_data是一个unordered_map<string, double>
// vec是一个vector<string>
double sum = 0;
for (auto& key : vec) {
    if (dict_data.count(key)) {// 或dict_data.count(key) > 0
        sum += dict_data[key]; // 或 sum += dict_data.at(key);
    }
}

或者：

for (auto& key : vec) {
    if (dict_data.find(key) != dict_data.end()) {
        sum += dict_data[key]; // 或 sum += dict_data.at(key);
    }
}

其实，map或unordered_map的[]或者at[]函数内部也会仔细查找。不管这次查找开销大或不大。既然已经查找过一次key是否存在，那么把结果存下来就好，为什么要两次查询呢？

for (auto& key : vec) {
    auto it = dict_data.find(key);
    if (it != dict_data.end()) {
        sum += it->second;
    }
}

可能有人觉得这样丑点，所以不这样写，但我们的原则一向是不要进行重复操作。

对于vector也有at()，所以也有人这样写：

if (index < v.size()) {
    auto& e = v.at(index);
    // do sth for e
    ... 
}

这个at()内部同样会检查是否越界，并在越界的时候抛出异常。所以对于vector直接[]就好，vector的[]几乎没有开销，和那些关联容器不同。

if (index < v.size()) {
    auto& e = v[index];
    // do sth for e
    ... 
}

或者直接不检查，而是直接佳try catch

try {
    ...
    auto& e = v.at[index];
    // do sth for e
    ... 
} catch (...) {

}

不鼓励在生产环境中使用会抛异常的函数。因为C++不同于java。java如果有未捕获或throw的异常，编译都过不了。而C++则不管。所以，如果你的代码不小心抛出了异常，而没有被catch，那么就可能让程序core dump。

1.4 sort给定义对象排序，可能存在对象拷贝的开销

STL中的sort()应该是一个高频使用的函数。比如对于一个vector进行排序。当vector存储的时候自定义类型的时候，我们给sort()传入一个比较算子，或者在外部重载一下operator<增加一个自定义类型的比较功能。

但自定义类型没有移动构造函数的时候，调用的是拷贝构造函数！当然如果类型比较简单（比如只是保护2个基本数据类型）那么拷贝构造的开销也不大。但如果自定义类型比较复杂的时候，拷贝构造的开销显然大于移动构造函数。

所以最好给自定义对象添加一个移动构造函数，另外为了使sort()能够成功通过编译，在定义完移动构造函数以后，还要再定义一个移动赋值函数。

当然如果不想这么麻烦的话，那么用vector存储该类型的指针，然后传入一个该类型指针进行比较大小的lambda表达式，会是更简单的解决方案。只是这样对于老代码来说可能是侵入性的。而直接修改类定义的方法，则对老代码透明。

1.5 如果要排序，不要无脑使用sort()

如果想着拥有N个元素的vector排序，然后取出K个元素。那么这是典型的TopK问题。不要无脑的使用sort()。STL的算法中还有一个partial_sort()，只帮助你找到最大（或最小）的K个元素，而不需要把整个vector变得有序。

2 STL中容易踩坑的副作用

2.1 clear()不会清空vector的内存

尽管clear()会调用vector中元素的析构函数，但是并不会释放掉元素所占用的内存。这并不难理解，因为在vector为空的时候，我们也可以用reserve()函数来预分配内存。所以vector所占的内存并不会随着元素的释放而释放。如果你想在vector生命周期结束之前及时释放掉vector的内存，请：

vector<int>().swap(v);

用一个匿名的vector对象来和已有的vector对象v来swap。虽然swap是交换，但由于涉及匿名对象，反过来swap是无法编译通过的：

v.swap(vector<int>()); // 编译失败

2.2 size()-1

如何遍历一个vector？当然在C++11以后我能手写for-range循环了。

for (auto& e: v) {
    // do sth for e
    ...
}

但是有时候我们在循环内需要下标信息，而不仅仅是元素本身。所以就变成传统的下标遍历了。有两种写法，各位看官看看是否有区别？

for (int i = 0; i < v.size(); ++i) {
    auto& e = v[i]
    // do sth for e and i
    ...
}

另外一种：

for (int i = 0; i <= v.size() - 1; ++i) {
    auto& e = v[i]
    // do sth for e and i
    ...
}

看起来好像一样？实则不然。因为size() 返回是无符号整型，当vector是空的时候，size()返回0，无符号的0 减去1，得到的是一个极大的正数。因而在vector是空的时候，第二种写法会陷入死循环！

2.3 int和size()比较

看过上一节内容，你是不是以为容器肯定大于0的时候，或者不去对size()做减一的时候，就没有什么副作用的地方了呢？那也未必。

实现一个二叉搜索树的迭代器，其中有个函数hashNext()返回还有没有下一个元素。next()表示向右移动虚拟的迭代器，并返回其值，所以我定义了一个成员变量i，初始化为-1。

    int next() {
        return tree[++i]->val;
    }    
    bool hasNext() {
        return i < tree.size() - 1;
    }
...
    int i = -1;
    vector<TreeNode*> tree;

题目保证容器肯定大于0，所以tree.size() - 1的结果最小也就是0（size()为1的时候）。在第一次调用next()的时候， i 是 -1，tree().size() - 1即使是0，也是满足小于关系的。所以hasNext()应该返回true，结果意外的是hasNext()返回的是false!

这个是因为tree.size()是无符号类型，有符号类型i在和它比较的时候被自动转型成了无符号的整型，所以取值为-1的i，变成了一个极大的整数，所以hasNext()返回了false！

这是一个常见的坑。

i < v.size()

这种表达式，在i会自动转型成无符号整型，然后你本以为的i（负数）小于v.size() (大于等于0），却判断成了大于！从而触发一下程序逻辑上的bug。

2.4 多线程一写多读STL容器也不是线程安全的

并发多个线程去写STL容器（“写”指的是插入新元素） 不是线程安全的，可能会触发core dump。但大家可能常常忽略一种不常见的情况：一个线程写，其他线程都是读的时候 其实也不是线程安全的。

比如vector，尽管只有一个线程来写入，但是如果他触发了扩容了。那么其他线程尽管是只读这个vector的，其中的迭代器也会失效。对于unordered_map也是类似，单线程不停插入元素的话，可能触发rehash，导致其他线程中在unordered_map中find的过程中core dump。