Example Analysis of two small tips of vector in C++

This article mainly introduces the example analysis of two small tips of vector in C++. The article is very detailed and has certain reference value. Interested friends must finish reading it!

Vector capacity expansion

It's a classic question, but I still accidentally stepped on it. One requirement is to copy the target element, and the collection of target elements is stored in vector, so after a brief thought, there is the following code (general meaning):

Void Duplidate (vector* element_list, Element* element) {element_list.push_back (* element);} void Process () {for (auto& package: package_list) {if (IsNeedDuplicate ()) {Duplicate (element_list, package- > element);}

There seems to be no problem, that is, whether the current package object meets the replication requirements, and if necessary, copy the origin_element, a member of package. It's normal to run UT, and then coredump during the test. Look, the core file is hung when copying. I didn't understand why a simple copy would have coredump in the first place.

I checked the element replication scenario for a long time and even wanted to write a copy constructor. Finally, it dawned on me that the origin_element pointer points to the elements in the element_list, the element_list is the data source of the overall process, and the packge object is the encapsulated intermediate processing object. For convenience, previous developers saved the original element pointer directly on the package object, which points to an element in a vector. My new logic will add elements to the original vector, which may lead to vector expansion, while vector expansion will lead to overall replication, resulting in invalidation of pointers to these elements, and subsequent package objects to access origin_element will generate coredump.

Of course, by design, pointers to vector elements should not be kept, but there is too much old code involved and will not be discussed here.

Vector::erase ()

The reason is that I added the following code to the code (roughly):

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

Then cr's classmate asked a question: element_iter is const immutable, but there is a corresponding element erased in the function, will there be a problem here? Although UT has already run, but this kind of writing is really strange, so I took the opportunity to learn the implementation principle and usage of vector::erase ().

The implementation principle of erase (iterator) does not actually change the iterator, but moves the following elements forward one by one, which means that the element pointed to by the iterator itself has changed, so you can modify the iterator with const. But the use of cosnt here is actually an unmistakable but useless embellishment, which is of no practical use except that it is easy to be misjudged. I changed reference to const reference in order to fix cpplint.

In addition, erase itself is really dangerous. When it comes to erase, iterator itself does not change, but the pointing element has changed. In many cases, iterator will naturally point to the next element, but because this is an undefined behavior, there may be something unexpected in it, so it will eventually be changed to the displayed get and return re-assignment (erase () will return the next iterator, but this is often ignored). So you can keep it safe. A safer and more recommended approach would be to use remove_if () and not to talk about it here.

Void EraseElement (vector& element_list,vector::iterator element_iter) {while (element_iter! = element_list.end ()) {element_iter = element_list.erase (element_iter);}} these are all the contents of this article entitled "sample Analysis of two Little tips of vector in C++". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!