C++ for loop performance
Author
Hello,
I've read or heard (mostly read) that
for(int i=0; i<1000; ++i)
has better performance than the classic
for(int i=0; i<1000; i++)
Can anyone enlighten me?
thank you.
People like to spread FUD about C++. There will be no difference in speed between the two.
Actually, postfix ++ (as in i++) is usually implemented by making a copy of the value, incrementing the original and returning the copy -- prefix ++ is just incrementing the value. But given that int is a primitive type (i.e., it does not have an overloaded op ++ which would result in a function call) and that you're not using the fact that i++ has different semantics from ++i, the compiler will most likely translate them both to the same code.
As a general rule, don't worry about microoptimizations like that -- they're useless. Optimize your algorithms.
Actually, postfix ++ (as in i++) is usually implemented by making a copy of the value, incrementing the original and returning the copy -- prefix ++ is just incrementing the value. But given that int is a primitive type (i.e., it does not have an overloaded op ++ which would result in a function call) and that you're not using the fact that i++ has different semantics from ++i, the compiler will most likely translate them both to the same code.
As a general rule, don't worry about microoptimizations like that -- they're useless. Optimize your algorithms.
++i is called pre-increment. i++ is called post-increment.
Since i is an int here (or really, if it were any POD) there is no real difference. The difference comes in if that is a heavy class.
The reason is because ++i just increments the value and returns the new value. So int i = 5; std::cout << ++i; would output 6.
The other option, i++, must return a copy of i's original value and then increment i. Meaning now there are two ints here instead of just one. So int i = 5; std::cout << i++; would output 5. However after that line i's value is 6. That's because it isn't actually outputting i, it is outputting that copy of i's original value.
Like I said before, for ints it won't matter. But if i was some huge, heavy class and creating a new copy is expensive then you'll notice a difference.
Since i is an int here (or really, if it were any POD) there is no real difference. The difference comes in if that is a heavy class.
The reason is because ++i just increments the value and returns the new value. So int i = 5; std::cout << ++i; would output 6.
The other option, i++, must return a copy of i's original value and then increment i. Meaning now there are two ints here instead of just one. So int i = 5; std::cout << i++; would output 5. However after that line i's value is 6. That's because it isn't actually outputting i, it is outputting that copy of i's original value.
Like I said before, for ints it won't matter. But if i was some huge, heavy class and creating a new copy is expensive then you'll notice a difference.
Quote:Original post by Oxyd
Actually, postfix ++ (as in i++) is usually implemented by making a copy of the value, incrementing the original and returning the copy -- prefix ++ is just incrementing the value. But given that int is a primitive type (i.e., it does not have an overloaded op ++ which would result in a function call) and that you're not using the fact that i++ has different semantics from ++i, the compiler will most likely translate them both to the same code.
As a general rule, don't worry about microoptimizations like that -- they're useless. Optimize your algorithms.
That's true, but it's still not a bad habit to use ++i instead of i++ in general, because for more complex types, it can make a difference. And since it doesn't really cost you anything (the code is no harder to read, and takes exactly the same number of characters to type), you might as well use the pre-increment version unless you actually need post-increment semantics.
Compiler will generate identical code for post- or pre-increment if functionality is identical. If one version made use of returned value, and another didn't, they wouldn't be identical.
The copy vs. no-copy behavior is relevant only if copy constructor or assignment operator causes side-effects (such as external function call). This may or may not happen with some STL iterators.
Simple rule is:
- Almost always, there will be no difference for functionally identical code
- On rare occasion, pre-increment can be marginally more efficient.
Some developers who make use of STL iterators prefer to use pre-increment consistently to avoid the above rare case.
The copy vs. no-copy behavior is relevant only if copy constructor or assignment operator causes side-effects (such as external function call). This may or may not happen with some STL iterators.
Simple rule is:
- Almost always, there will be no difference for functionally identical code
- On rare occasion, pre-increment can be marginally more efficient.
Some developers who make use of STL iterators prefer to use pre-increment consistently to avoid the above rare case.
I see no reason to use postincrement in this scenario. What do you gain by writing "i++"? Personally, I have come to like "++i" better, I read it naturally as "increment i".
@DevFred I like the look of the post increment syntax more because the majority of operators come after the variable name, so it seems more natural to me. I'm trying to get over it because I use pre-increment much more.
Author
I see, so it's just another MYTH.
Thanks.
P.S. I agree post-increment seems more natural to me (c++)
Thanks.
P.S. I agree post-increment seems more natural to me (c++)
Quote:Original post by DevFredAs have I.
Personally, I have come to like "++i" better, I read it naturally as "increment i".
Quote:Original post by ProgramMaxTo be exact, ++i reads the value of i, adds one to it, returns the new value, and stores the new value back at some point in time before the next sequence point.
The reason is because ++i just increments the value and returns the new value.
This is why code like a[++i] = i; or even foo(++i,++i) doesn't work: the time when the value is stored back is unknown, so the code is unpredictable.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
