Archived

This topic is now archived and is closed to further replies.

c++ can you compare iterators?

This topic is 5328 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

can you reliably compare stl iterators? I know iterators are kind of wierd (for example, if you remove an element from a set, all iterators on that set are invalidated), so I thought it might be possible that you cant compare them for some reason. for example,
vector<Vert>::iterator itr;
vector<Vert>::iterator itr2;
for (itr = bunchaVerts.begin(); itr != bunchaVerts.end(); itr++) {
for (itr2 = bunchaVerts.begin(); itr2 != bunchaVerts.end(); itr2++) {
if (itr == itr2)
cout<<"comparing Vert to itself so skipping..."<<endl;
}
}


Share on other sites
quote:
Original post by AndreTheGiant
can you reliably compare stl iterators?
I know iterators are kind of wierd (for example, if you remove an element from a set, all iterators on that set are invalidated), so I thought it might be possible that you cant compare them for some reason.

Yes, because your iterators are of the same forward_iterator class. However, it will not compare the values, only the addresses.

Try using a functor.

BTW, when you remove an iterator from a set, the return is the next iterator. What you do is continue the loop;

for(itr = list.begin(); itr != list.end(); itr++){//bad itemitr = list.erase(itr);if(itr == list.end())break;else {itr--; //back up onecontinue; //jump to the beginning of the loop//end bad item}}

Share on other sites
Just wondering, what is wrong with comparing the addresses instead of the values? Isnt this just as good? I mean, if the addresses are the same, then certainly the values are the same too right ?

Besides, I dont think I want it to compare values anyway now that I think of it. For example, if there happen to be 2 Verts at exactly the same location, then this is fine and I want the code to be executed as normal.

However, if there is only one Vert at a given location, but both my iterators are pointing to it, then this is the case that I want to skip ahead to the next iteration.

Share on other sites
quote:
Original post by AndreTheGiant
Just wondering, what is wrong with comparing the addresses instead of the values? Isnt this just as good? I mean, if the addresses are the same, then certainly the values are the same too right ?
Yes, but not vice versa. If that is acceptable, then you have no problems.

Share on other sites
Just a quick note, off the topic but related.

Whenever possible, use prefix increment/decrement operators. When using postfix, the operator is supposed to (and does, in the case of STL) return the value before the increment/decrement. This means that the operator has to return a full copy of the iterator by value, rather than just it''s own reference.

That is, ++itr is faster than itr++ (except prehaps for a very few certain sets, in which case they''ll be equivilant in speed).

This goes out to both AndreTheGiant (itr++ and itr2++ could be ++itr and ++itr2) as well as NatasDM (itr++ and itr-- could be ++itr and --itr).

Share on other sites
quote:
Original post by MaulingMonkey
This goes out to both AndreTheGiant (itr++ and itr2++ could be ++itr and ++itr2) as well as NatasDM (itr++ and itr-- could be ++itr and --itr).

I do this for integers and such, but I wasn''t quite sure how the unary and binary operators were implemented in the iterator class. I suppose it makes since.

Share on other sites
quote:
Original post by Oluseyi
quote:
Original post by AndreTheGiant
Just wondering, what is wrong with comparing the addresses instead of the values? Isnt this just as good? I mean, if the addresses are the same, then certainly the values are the same too right ?
Yes, but not vice versa. If that is acceptable, then you have no problems.

I was thinking that if he was using vector<vert> instead of vector<vert*> then there would be a problem as one involves a copy constructor when pushing the container and the other is a static place in memory.

I may very well be misunderstanding your explanation.

[edited by - natasdm on January 12, 2004 3:27:30 PM] (Stupid Tags)

[edited by - natasdm on January 12, 2004 3:30:50 PM]

Share on other sites
quote:
Original post by MaulingMonkey
This goes out to both AndreTheGiant (itr++ and itr2++ could be ++itr and ++itr2) as well as NatasDM (itr++ and itr-- could be ++itr and --itr).

Actually, the compiler would optimize both into the same thing anyway. So for the OP''s post, it wouldn''t make a difference.

Secondly, in a for loop, it makes a lot of difference. Just think about what would happen if the variable was incremented too early!

Share on other sites
quote:
Original post by psykr
Actually, the compiler would optimize both into the same thing anyway. So for the OP''s post, it wouldn''t make a difference.

Secondly, in a for loop, it makes a lot of difference. Just think about what would happen if the variable was incremented too early!

Relying on the compiler to optimize away something blindly is ill-advised. May as well do it right.

And, in the for loop, the early increment is still functionally the same, since it still happens after the run. It doesn''t change the logic.

I like pie.

1. 1
2. 2
frob
15
3. 3
Rutin
12
4. 4
5. 5

• 13
• 12
• 58
• 14
• 15
• Forum Statistics

• Total Topics
632124
• Total Posts
3004236

×