Printable View
Is it true that for built in types, pre increment and post increment have no effect on optimization?
i.e i++ and ++i does not optimize the code if "i" were an "int"?
I want to know :
1. what is difference from optimization point of view when u write "for" loop with i++ & ++i? (assume "i" is an int)
2. if in a statement I write ++i; instead of i++; does it optimize the code?
I think you'd be hard pushed to find a compiler that had a difference.
Even when you do, I'd say you'd be hard pushed to measure the difference.
++i is not necessarily faster than i++ for built-in types. As standalone expressions, they do the same thing and any compiler that's worth a damn will produce the same machine code for both.
VC++6 used to produce different machine code for tiny examples in debug mode. Used the EAX register for the preincrement and the EDX for the postincrement.
++i is a good habit to get into, because it's often faster for custom types such as complicated iterators.
I've heard of prescript causing as much as an an 8% increase in speed on DevC++. That was on a program that had lots of loops.
Could it be with the postfix version instead?
All the prefix operator does is to increment the value and return the incremented object. Whereas the postfix version needs to store the incremented value and return the unchanged one.
Arguably the compiler optimizes away any differences, but for complex iterations, I would be lead to believe it's the postfix version the slowest.
No, it was an increase in speed, not run time.Quote:
Originally Posted by Mario F.
Yes. I misread it.
well... post-increment can be seen as a function that stores the current value in a temporary, increments the value and returns the temporary.
so of course some compilers might not optimize that away - even on built in types.
The peephole optimiser (at least) should take care of the difference for built-in types. Of course many compilers might also perform a replace-postfix-with-prefix-where-possible optimisation at an earlier phase of compilation.
If you're a regular user of the standard C++ library, then using prefix for everything becomes the norm anyway, and there's no reason not to be consistent and use that for built-in types as well.