Jump to content
  • Advertisement

Archived

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

AndreTheGiant

c++ can you compare iterators?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 item

itr = list.erase(itr);
if(itr == list.end())break;
else {itr--; //back up one

continue; //jump to the beginning of the loop

//end bad item

}
}

Share this post


Link to post
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.

thanks for your reply. Hope Im on the right track!

Share this post


Link to post
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 this post


Link to post
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).

Just a fyi, I didn''t know about this for the longest time myself.

Share this post


Link to post
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).

Just a fyi, I didn''t know about this for the longest time myself.


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.

Thanks for the heads up.

Share this post


Link to post
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 this post


Link to post
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).

Just a fyi, I didn''t know about this for the longest time myself.


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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!