本来这篇文章标题我想起成《关于 vector 的两个小坑》,后来想想,其实也不算是坑,还是自己对原理性的东西理解的没做那么透彻。工作中遇到的很多问题,后来归根到底都是基础不牢靠。

vector 扩容

这个问题很经典了,但还是不小心踩到。有一个需求是要对目标元素进行复制,而目标元素集合是保存在 vector 里面,于是简单思考下就有如下代码(大致含义):

void Duplidate(vector<Element>* element_list, Element* element) {
  element_list.push_back(*element);
}

void Process() {
  for (auto& package : package_list) {
    if (IsNeedDuplicate()) {
      Duplicate(element_list, package->element);
    }
  }
}

看起来好像没什么问题,就是当前的 package 对象是否满足复制的要求,需要的话,就对 package 的成员 origin_element 进行复制。跑 UT 也正常,然后在测试的时候就 coredump 了。看 core 文件就是挂在了复制的时候。这里我一开始就没明白,一个简单的复制为什么会有 coredump。

检查了很久 element 复制的场景,甚至想要专门写一个拷贝构造函数。最后才恍然大悟,origin_element 指针指向的就是 element_list 里面的元素,element_list 是整体流程的数据源,packge 对象是封装的中间处理对象。之前的开发人员为了方便,直接在 package 对象上保存了原始的 element 指针,而这个指针指向的是一个 vector 里的元素。而我新加的逻辑会往原始的 vector 里面再添加元素,那么就有可能导致 vector 扩容,而 vector 扩容会导致整体的复制,从而导致原来指向这些元素的指针都失效了,靠后的 package 对象再去访问 origin_element 就产生了 coredump。

当然,从设计上来说,就不应该保存指向 vector 元素的指针,但是这里有太多旧代码牵涉,这里就不做讨论。

vector::erase()

起因是我在代码里面新增了如下代码(大致):

void EraseElement(const vector<Element>::iterator& element_iter,
                vector<Element>& element_list) {
  while (element_iter != element_list.end()) {
    element_list.erase(element_iter);
  }
}

然后 cr 的同学提出了一个疑问是 element_iterconst 不可变的,但是在函数里有擦除了对应的元素,这里会不会有问题?虽然 UT 都已经跑过了,但是这种写法的确比较奇怪,于是就借机学习了一下 vector::erase() 的实现原理跟用法。

erase(iterator) 的实现原理其实不会改变 iterator,而是把后面的元素一个个往前移动,相当于是 iterator 指向的元素本身发生了变化,所以可以用 const 来修饰这个 iterator。但是这里用 cosnt & 其实是没有错但是无用的修饰,除了容易让人误判之外,其实没有什么实际用途。我之前是为了修正 cpplint 才把reference 改成 const reference。

另外 erase 本身的确比较危险,主要还是 erase 的时候 iterator 本身没发生变化,但是指向的元素变了,,在很多时候 iterator 会自然地指向下一个元素,但是由于这是未定义的行为,这里面可能会有不可预期的地方,所以最终改成显示的获取返回重新赋值(erase() 会返回下一个迭代器,但这一点常常被忽略),这样就能保证安全性了。更安全更推荐的做法应该是使用 remove_if() 这里就不展开讲了。

void EraseElement(vector<Element>& element_list,
                vector<Element>::iterator element_iter ) {
  while (element_iter != element_list.end()) {
    element_iter = element_list.erase(element_iter);
  }
}

findingea
1.1k 声望64 粉丝

« 上一篇
我的校招回顾