Printable View
If I'm iterating thru, eg, a 5000 member vector, is it worthwhile to do this:
rather than justCode:vector<whatever>::iterator it = myvec.begin(), end = myvec.end();
while (it != end) {
or will the compiler optimize this anyway? I would think since myvect could be shortened in the loop it cannot...Code:while (it != myvec.end()) {
The compiler can't optimize anything away arbitrarily, especially as you say that the loop will invalidate the end iterator. If that is the case, you can't use a cached end iterator in the first place.
Well, I meant in the case where I could (because I am not actually going to shorten anything, but the compiler cannot deduce that), is it worth it? I am presuming yes, but I thought I'd ask in case for some reason checking a value vs. returning one from a method here amounts to six vs two threes...Quote:
Originally Posted by anon
If the one past the end iterator is not going to change, then it may be good to cache it in a variable that is declared constant just to document this fact, even if there is no measurable improvement in efficiency.
just on the basis of my pretty rudimentary understanding of how these iterators work, i would think assigning the value would almost have to be at least a little bit better.
if it's at all reasonable in the specific case, though, i'd try converting it to
but maybe i'm just over-fascinated by some of the STL possibilities since I only recently started working with them.Code:for_each(myvec.begin(), myvec.end(), myfunction);
I would look at it the other way around -- only use for_each if there is no other way, or it is significantly more convenient. I also imagine "for_each" is more intended for random access containers. Nb, it adds a functional call each time and is very unlikely to be more efficient than using iterators yerself.Quote:
Originally Posted by Aisthesis
Always good to learn new things, but don't misconceive of their value just because they seem clever ;)
A loop can always replace the use of std::for_each, so there certainly will never be "no other way". Even if it is convenient, it would be better to use another generic algorithm that better describes what is happening.Quote:
Originally Posted by MK27
std::for_each just requires input iterators.Quote:
Originally Posted by MK27
If you are going to call a function that is not inlined anyway, then it would not make a difference. If you use a function object, the call might be inlined, and thus again it would not make a difference. What might be inconvenient is that you may need to define the function or function object yourself, and the logic contained in them is separated from the place where it is used (possibly just once). Unfortunately, we have to wait for lambda support or use non-standard libraries as a current workaround.Quote:
Originally Posted by MK27
Until C++0x allows this at language level:
Usually most convenient, however I couldn't tell if there might be a performance penalty.Code:BOOST_FOREACH(whatever& we, myvec) { ... }