can i compare iterators to see if they point to the same object?
Author
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!
Quote:Original post by graveyard fillaYes. 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).
can i do it1 == it2 to see if they are "pointing" to the same object?
Bluentrue: consider the following:
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.
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.
Author
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.
thanks for any help.
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.)
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.)
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.
of course if they arent pointing to the same thing != is to be applied =) but he has for a comparison and thats what i use.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
