Does the gcc compiler optimize the following code? std::vector v(5); std::vector::iterator it; for(it = v.begin(); it != v.end(); it++) Or is it faster to do this: std::vector v(5); std::vector::iterator it; std::vector::iterator end(v.end()); for(it = v.begin(); it != end; ++it) Note that the temp variable end, and the preincrement of it. I was reading Exceptional C++ and it says the second way is faster, but I'm wondering if the comipler has gotten better since the boo
file I-485, 131 and 765 together. If your immigration petition is still pending and you are worry 如果被拒, then don't file his I-485 until your I-130/I-140/I-360... is approved.
The 2 differences both make sense to me. v.end() is called each loop, which is unnecessary. ++ it does not make a copy of iterator compared to it++. I don't think compiler should optimize either of those, I could be wrong tho .
y*a
12 楼
if you only hoist the end() out of the loop and not the "begin()". I think oftentimes it doesn't make any difference. The reason the hoisting is good is because after hoisting, it is easier for the compiler to figure out the upper-bound of the loop is loop-invariant. but you only know the upper-bound is constant in the loop but don't know the lower-bound, it really doesn't help much. Unless you knw both bounds are constant, compiler can do soem tricks for better performance.
【在 j****i 的大作中提到】 : Does the gcc compiler optimize the following code? : std::vector v(5); : std::vector::iterator it; : for(it = v.begin(); it != v.end(); it++) : Or is it faster to do this: : std::vector v(5); : std::vector::iterator it; : std::vector::iterator end(v.end()); : for(it = v.begin(); it != end; ++it) : Note that the temp variable end, and the preincrement of it.
d*p
13 楼
It is a good habit to do so - expert C++ coders write this way in boost libraries. However, most mainstream compilers are able to achieve optimal code in even the 1st situation. So it does not matter actually.
【在 j****i 的大作中提到】 : Does the gcc compiler optimize the following code? : std::vector v(5); : std::vector::iterator it; : for(it = v.begin(); it != v.end(); it++) : Or is it faster to do this: : std::vector v(5); : std::vector::iterator it; : std::vector::iterator end(v.end()); : for(it = v.begin(); it != end; ++it) : Note that the temp variable end, and the preincrement of it.
y*a
14 楼
compilers can be used to optimize this kind of code. But to say "it doesn't matter actually" is really far-fetched. The fact is that the compielr can b e easily confused and then gives up the optimizations that are easy from the user point of view. to do that, comipiler has to do good inlining to eliminate the member functi on calls (many compiler does poor job on that). oftentimes actually this is the easist thing, it has some benefit because it eliminates function call overhead. but oftentimes
d*p
15 楼
Thanks for sharing a lot of insightful info about this issue. I wish to further put up some stuff which is not guaranteed to be right :-) Let's narrow down the topic to the vector iterator optimization issue. My obversation as a user is 1. Withut optimization option turned on, a few compilers (gcc on os x/linux and CC on solaris) are able to move begin/end iterator access function out of loop 2. With optimization turned on, the above access functions are inlined 3. The compiler is smart not movi
【在 y***a 的大作中提到】 : compilers can be used to optimize this kind of code. But to say "it doesn't : matter actually" is really far-fetched. The fact is that the compielr can b : e easily confused and then gives up the optimizations that are easy from the : user point of view. : to do that, comipiler has to do good inlining to eliminate the member functi : on calls (many compiler does poor job on that). : oftentimes actually this is the easist thing, it has some benefit because it : eliminates function call overhead. but oftentimes
j*i
16 楼
谢谢各位讨论, 受教了.
linux if even
【在 d****p 的大作中提到】 : Thanks for sharing a lot of insightful info about this issue. : I wish to further put up some stuff which is not guaranteed to be right :-) : Let's narrow down the topic to the vector iterator optimization issue. : My obversation as a user is : 1. Withut optimization option turned on, a few compilers (gcc on os x/linux : and CC on solaris) are able to move begin/end iterator access function out : of loop : 2. With optimization turned on, the above access functions are inlined : 3. The compiler is smart not movi