Jump to content
  • Advertisement
Sign in to follow this  
graveyard filla

can i compare iterators to see if they point to the same object?

This topic is 4952 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

hi, quick question. lets say i have 2 iterators. can i do it1 == it2 to see if they are "pointing" to the same object? if not, couldn't i just do &*it1 == &*it2? will the latter be faster since its doing a pointer compare? thanks for any help!

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by graveyard filla
can i do it1 == it2 to see if they are "pointing" to the same object?
Yes. The iterator concept is a superset of the pointer concept, so that interface element remains consistent (as do most others, like advancing through a sequence).

Share this post


Link to post
Share on other sites
Bluentrue: consider the following:


std::list<int> l;
l.push_back( 18 ); l.push_back( 18 );
std::list<int>::iterator it1 = l.begin( ), it2 = l.begin( ) + 1;


In that case, (*it1) == (*it2) but it1 != it2. This is because it and it2 are not pointing to the same object, but the values of the two objects pointed to by it1 and it2 are equal.

Share this post


Link to post
Share on other sites
so, is comparing pointer values (&*it1 == &*it2) faster then using iterators (it1==it2)? this is for a MORPG server so im trying to squeeze out every last bit of performance. (please spare me the pre mature optimization speach [smile])

thanks for any help.

Share this post


Link to post
Share on other sites
That would depend on the implementation. My money's on 'no'; it would be easy enough to have a pointer-based comparison in the iterator's comparison operator.

Edit: I'm sorry, but this is pertinent to the premature optimisation argument. Never look for contrived ways of making things go slightly faster unless you have good reason to believe they need to. And assume that library implementors know what they're doing—if pointer comparison would be faster, why wouldn't they use it in the first place? (Probably, but not certainly, a rhetorical question.)

Share this post


Link to post
Share on other sites
on the early optimization thing: code optimization should never be done unless done with a profiler, otherwhise you will probably end up optimizing the wrong code and probably making it run slower. speed is unimportant unless you're gearing up for release. the main thing to think about early on is getting it to work, not getting it to work faster.

Share this post


Link to post
Share on other sites
Even if the pointer comparison is faster than the iterator comparison, it's unlikely to outweigh the two extra overloaded operator*'s and two dereferences. My guess is that it costs as much as a member selection for each iterator and then the pointer comparison.

Share this post


Link to post
Share on other sites
It depends on what's in the iterators too, as demonstrated by the "list of ints" example.

A quick hint if you want to optimise STL: If you're using something like a vector, grab a pointer to the first element and use it like a pointer of pointers (array) in all your time critical sections of code. E.g.

Object** p = &vecOfObjects[0];

for (int i = 0; i < vecOfObjects.size(); ++i)
{
p->Update(); // etc.
}

Iterating through STL containers is pretty slow.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!