My understanding is the iterators of associative containers are not invalidated during insert or erase (unless the node pointed by iterator is erased). But in the below program
the insert seems to invalidate the iterator. Is my understanding wrong?
typedef std::set<unsigned int> myset_t;
int main(int argc, char **argv)
{
myset_t rs;
myset_t::reverse_iterator rit;
myset_t::reverse_iterator srit;
int ii = 500;
rs.insert(10);
rs.insert(11);
rs.insert(12);
rs.insert(13);
rs.insert(14);
rs.insert(100000);
rs.insert(102000);
rs.insert(103000);
rit = rs.rbegin();
while(rit != rs.rend()) {
srit = rit;
if (*rit < 100000) {
cout << "bailing here " << *rit << endl;
return 0;
}
rit++;
cout << "Before erase " << *rit << endl;
rs.erase(*srit);
cout << "Before insert " << *rit << endl;
rs.insert(ii);
cout << "After insert " << *rit << endl;
ii++;
}
cout << "Out of loop" << endl;
}
===
The output is
Before erase 102000
Before insert 102000
After insert 14
bailing here 14
=====
The promised behavior for iterators of a standard container does not hold for reverse iterators of that container.
A reverse iterator actually stores, as a member, the normal (forward moving) iterator which comes after the element to which the reverse iterator refers when dereferenced. Then when you dereference the reverse iterator, essentially it decrements a copy of this stored normal iterator and dereferences that. So this is a problem:
rit = rs.rbegin(); // rit stores rs.end()
srit = rit; // srit also stores rs.end()
rit++; // rit stores a normal iterator pointing to the last element
rs.erase(*srit); // this deletes the last element, invalidating the normal
// iterator which is stored in rit. Funnily enough, the
// one stored in srit remains valid, but now *srit is a
// different value
Reverse iterators behave this way because there is no "before begin" iterator. If they stored the iterator to the element to which they actually refer, what would rs.rend() store? I'm sure there are ways around this, but I guess they required compromises which the standards committee was not willing to make. Or perhaps they never considered this problem, or didn't consider it significant enough.
Related
I do not know, why does it output 1024?
vector<int> default_container = { 1,2,3,4,5,6,7,78,8,1024 };
cout << *default_container.end() << endl; // 0
default_container.pop_back();
for (auto it : default_container)
{
cout << it << ",";
}
cout << endl;
cout << *default_container.end() << endl; // 1024 why？why？why？why？
cout << *--default_container.end() << endl; // 8
Your program has Undefined behavior!
You are de-referencing the end iterator, at the lines
cout << *default_container.end() << endl;
...
cout << *default_container.end() << endl;
which gives you undefined behavior. Form cppreference.com the std::vector::end, std::vector::cend
Returns an iterator to the element following the last element of the vector.
This element acts as a placeholder; attempting to access it results in undefined behavior.
Means, anything can be happened; therefore you shouldn't be relaying on its result and should not be doing it!
That being said, it looks like that you want to access the last element in the vector. If that the case, for a non-empty vector you have multiple other (safe) choices:
Using std::vector::back
// prints first 8 from last; due to "default_container.pop_back()"
std::cout << default_container.back();
Using std::prev
#include <iterator>
// prints first 8 from last; due to "default_container.pop_back()"
std::cout << *std::prev(default_container.end());
Using reverse iterator std::rbegin
// prints first 8 from last; due to "default_container.pop_back()"
std::cout << *std::rbegin(default_container);
As a side note, see: Why is "using namespace std;" considered bad practice?
The previous answer says it all.
In other words you're not supposed to use end() for anything else then comparing an iterator to.
Eg.
for (auto it = container.begin(); it < container.end(); ++it)
Also note that your line for (auto it : default_container)
isn't creating an iterator but literally an int.
// foreach value in container
for(int value : default_container)
{
cout << value;
}
note that if you're not planning to change the values you're iterating over you can use this :
for(const auto value : default_container) {}
or if your containter contains objects (instance of classes)
for(const auto& object : container) {}
I want to iterate through a vector of pointers pointing on objects. While iterating, I have to push_back new pointers to the vector. Before the loop, the number of push_backs is unknown and there is no abort criterion, so that I can't use a while loop.
Here is an example using pointers on integers, that shows the same error as the version with objects: Segmentation fault (core dumped) after one iteration.
vector<int*> vec;
int a = 43;
vec.push_back(&a);
for (vector<int*>::iterator it = vec.begin(); it != vec.end(); ++it) {
cout << *(*it) << " " << *it << endl;
vec.push_back(&a);
}
The same Code but with integers works great.
vector <int>vec;
int a = 43;
vec.push_back (a);
for (vector < int >::iterator it = vec.begin (); it != vec.end (); ++it){
cout << (*it) << " " << *it << endl;
vec.push_back (a);
}
push_back invalidates the iterator when appending results in size > capacity so it reallocates and copies to the new space.
Appends the given element value to the end of the container.
1) The new element is initialized as a copy of value.
2) value is moved into the new element.
If the new size() is greater than capacity() then all iterators and
references (including the past-the-end iterator) are invalidated.
Otherwise only the past-the-end iterator is invalidated.
Plus as #Jesper pointed out you are storing a reference to a local variable in your vector:
int a = 43;
vec.push_back(&a);
which if went out of scope before your vector you will have dangling references.
I have two maps. The keys of the two maps are the same. The mapped-value of the second one is a pointer, which points to the mapped-value of the first one. When I erase the element in the first map, the pointer in the second map does not vanish automatically. I should first erase the second map and then erase the first one.
// two maps
map<int, int> a;
map<int, int*> pt_a;
int N = 5;
for (size_t i = 0; i < N; i++)
{
a.insert({ i,2 * i });
pt_a.insert({ i,&(a[i]) });
}
// erase the first element of a
a.erase(a.begin());
// after erase
for (auto& i : a) cout << i.first << " " << &(i.second) << endl;
cout << endl;
for (auto& i : pt_a) cout << i.first << " " << i.second << endl;
Is there anything in C++ can simplify this code? If the element in the first map is erased, the corresponding one in the second map is also erased automatically.
If I erase the element in the second map, the memory of pointer is free or not? Should I use std::share_ptr in this case?
Thanks!
Have searched the net a lot, but couldn't find the answer to the issue.
I am inserting a value to an std::list using its reverse_iterator. While the insertion occurs at the appropriate position as expected, what I noticed is that the value of the original reverse_iterator used for insertion changes. Also the value of a completely unrelated reverse_iterator too changes. I have been able to reproduce this in a simple example
#include <iostream>
#include <list>
#include <string>
int main()
{
// Creating a list of values 1, 2, 4, 5
std::list<int> myList;
myList.push_back(1);
myList.push_back(2);
myList.push_back(4);
myList.push_back(5);
// Changing it to 1, 2, 3, 4, 5 by inserting 3
std::list<int>::reverse_iterator revIter = myList.rbegin();
while(2 != *revIter)
{
std::cout << *revIter << "\t";
++revIter;
}
std::cout << "\n" << "Reverse iterator now points to " << *revIter;
// Creating a copy of the reverse Iter before inserting.
std::list<int>::reverse_iterator newRevIter = revIter;
myList.insert(revIter.base(), 3);
// Checking the values of revIter and newRevIter
std::cout << "\n" << "Reverse Iterator now points to " << *revIter; // UNEXPECTED RESULT HERE
std::cout << "\n" << "New Reverse Iterator now points to " << *newRevIter; // UNEXPRECTED RESULT HERE
std::cout << "\n" << "Printing final list:" << "\n";
for(std::list<int>::iterator iter = myList.begin(); myList.end() != iter; ++iter)
{
std::cout << *iter << "\t"; // Results are fine
}
return 0;
}
RESULT
5 4
Reverse iterator now points to 2
Reverse iterator now points to 3
New Reverse iterator now points to 3
Printing final list:
1 2 3 4 5
Is this expected behaviour. If so how can reverse iterator be used to insert items to a list (Or is it useless in this regard)?
I would avoid using reverse iterators (in general, and in particular for anything other than a sequential transversal). Forward and reverse iterators work differently, in the case of a forward iterator into a list, the iterator tracks the node that you access through operator*, but in the reverse case the iterator tracks the next element in the list. The act of dereferencing a reverse iterator obtains the predecessor of the node referred by the iterator and extracts the value from that. Graphically (f is a forward iterator, r is a reverse iterator)
f
1 2 4
r
Both the forward iterator f and the reverse iterator r will yield 2 when dereferenced, but the node they track is different. When you insert using r you insert between 2 and 4, but the underlying iterator is left pointing to the node holding the 4:
f
1 2 3 4
r
Now if you dereference r, the same process as above applies. The predecessor of the current node is obtained, and the value printed, except that now the predecessor of 4 is 3 and that is what you get.
Is this expected behaviour. If so how can reverse iterator be used to insert items to a list (Or is it useless in this regard)?
Yes, this is expected behavior. How can a reverse iterator be used to insert items to a list? Understanding how it works.
The invariant after insertion is the std::reverse_iterator<>::base(), not the std::reverse_iterator<> itself. But, base() does target the previous elements compared to reverse_iterator:
http://en.cppreference.com/w/cpp/iterator/reverse_iterator
What's bother me a bit is that when I had std::distance to the begin() (or rend().base() ):
std::cout << "\n"
<< "Reverse Iterator now points to "
<< *revIter << "-" << *(revIter.base())<< "-"
<< std::distance(revIter.base(), myList.rend().base());
I have:
Reverse iterator now points to 2-4-3
Reverse Iterator now points to 3-4-3
Or I expect the second one to be "3-4-4" as the element is inserted prior to the base()...
I am traversing an std::list using reverse iterators and erasing some elements from the list using their forward iterators that were obtained when inserting them. A sample program is shown below. I read that deleting elements from a list doesn't invalidate other iterators except for the ones referring to element that's deleted. But there's no mention of reverse_iterators and my program is crashing. Can someone please tell if the usage is incorrect?
What the program is doing is adding an element into the list, storing its iterator, reverse iterating the list and deleting the only element in the list using its stored iterator.
The output is pasted below the code sample.
#include <list>
#include <iostream>
using namespace std;
struct node
{
int data;
list<node*>::iterator iter;
} a;
int main()
{
list<node*> l;
a.data = 1;
l.push_front( &a );
a.iter = l.begin();
list<node*>::reverse_iterator ri = l.rbegin();
while ( ri != l.rend() )
{
cout << (*ri)->data << endl;
list<node*>::reverse_iterator rj = ri;
++ri;
if ( ri == l.rend() )
cout << "before erase: reached end" << endl;
l.erase((*rj)->iter);
if ( ri == l.rend() )
cout << "after erase : reached end" << endl;
else
cout << "after erase : Not reached end" << endl;
}
}
OUTPUT
1
before erase: reached end
after erase : Not reached end
610568524
before erase : reached end
Segmentation fault
Under VS2010 it will throw an exception here, on the first loop pass:
l.erase((*rj)->iter);
if ( ri == l.rend() ) // exception
That should give you a general idea what's going on. You see, reverse_iterator is just a wrapper for standard iterator. That said, you should remember that it's got base() member that returns underlying iterator - you don't have to store it elsewhere, like you do in node struct.
Here's a great answer to how reverse_iterator relates to the iterator. In your case, rbegin will be based on begin iterator. If you remove the begin from the list (which you do, since it has only one element), all reverse_iterators based on this iterator will become invalid. Keeping that in mind you could rewrite your loop the following way:
while ( ri != l.rend() )
{
cout << (*ri)->data << endl;
list<node*>::reverse_iterator rj = ri;
++ri;
if ( ri == l.rend() )
cout << "before erase: reached end" << endl;
// the actual underlying iterator has an offset of one
list<node*>::iterator it = l.erase(--rj.base());
ri = reverse_iterator<list<node*>::iterator>(it);
// or just
// ri = reverse_iterator<list<node*>::iterator>(l.erase(--rj.base()));
if ( ri == l.rend() )
cout << "after erase : reached end" << endl;
else
cout << "after erase : Not reached end" << endl;
}
The reverse iterator is (tpyically) not a unique class, but a adapter on a normal iterator - it has a iterator into a list as member and uses it to do its own moving and dereferencing. So when this list iterator gets invalidated, the reverse iterator is invalidated too.
i'm writing an answer to note my findings; if you hit this problem try
SingerOfTheFall 's suggested method, it works like a charm, example:
for(auto it=values.end();it!=values.begin();){
if((*it).second.endPoint)
break;
values.erase((*(it--)).first);
}
back to my findings about this:
when i hit the problem the program hanged, and i've run a valgrind check, it dropped out some strange Invalid reads originated from libstdc++
Invalid read of size 8
at 0x4EAA633: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
by 0x402FEC: std::_Rb_tree_iterator<std::pair<int const, GroupControl::Group::Entry> >::operator--() (stl_tree.h:218)
i suspect that after the last element's erase the rend() doesnt stop the iterator, and the ++ op is trapped in a loop
You need store erase return value into iterator. Do following change.
(*rj)->iter= l.erase((*rj)->iter);