Personally, I'd expect a compiler to take it one step further than what was suggested here.
For example, clang or gcc (under -O1) will precompute all of the math in that for-loop, and the entire function just becomes the printf with a known value.
If you read all the way into the comments, you'll see that this does happen -- but only for values of n that are quite small. And this is a side effect of other optimizations -- not because of anything specific to this closed form.
I don't believe that's right (see below why). Point me to one compiler which does this intentionally (ie not a bug) and I would stand corrected, but in most cases most compiler experts I know (myself included) would frown and disapprove. There was a bug in GCC a while ago to that effect, but it's been corrected since.
Why: Computationally, there is no difference between "no code" and "a loop that iterates 100 times and does nothing". It is thus correct to eliminate the latter to preserve the observable behaviour. However, a loop that never terminates is a very different thing entirely: it says "execution will never progress past this point" and everything afterwards will never be reached. This property is so enshrined in theoretical computer science that any half-decent verification tool will consider what comes after the loop as dead code and not check it. In the newer GCC and Clang the code after a never-ending loop will be marked "unreachable" and be killed as dead code.
So removing a never-ending loop would be quite the big deal indeed.
Technical note: specifically in C and C++ and every language implemented using them, a loop with a counter but no check on the upper bound (eg. "for(i = 0; ; ++i)" ) is very different from the empty loop discussed above. Such a loop would be called "undefined behavior": the program may or may not stop, the world may explode, etc. This is because C and C++ say that overflow has undefined behavior. So this kind of loop does not mean "the programmer intends the control flow to terminate here", but rather "the programmer is playing with fire and it can burn".
This gets repeated a lot, but I'll say it again anyway:
MSVC is a C++ compiler. It happens to support some C99 (and will support more in VS2013, actually), but that's not its focus. While I, and many other Windows developers, feel that its standard compliance has fallen a bit behind in the last five years or so, Microsoft has made tremendous strides towards fixing that problem lately, and the roadmap (http://blogs.msdn.com/b/somasegar/archive/2013/06/28/1042993...) for full C++11/14 compliance looks good, and seems reasonable. Further, while C++11/14 compliance in MSVC isn't amazing, its compilation speed, and the optimizations it can deliver to its compiled executables, are both top-notch. VC++ generally seems to land between GCC and ICC for most code I write.
Is it perfect? No. Should it support more of C++11 and 14? Yes, and they're working on it. But as much as I wish there were a great C99 compiler on Windows, Microsoft has been open for a very, very long time that that's simply not their focus. Just as I don't assail Apple for Xcode's lousy Python support, I don't see a point in attacking MSVC for not doing C support.
[+] [-] sharth|12 years ago|reply
For example, clang or gcc (under -O1) will precompute all of the math in that for-loop, and the entire function just becomes the printf with a known value.
[+] [-] CurtHagenlocher|12 years ago|reply
[+] [-] octo_t|12 years ago|reply
[+] [-] knz42|12 years ago|reply
Why: Computationally, there is no difference between "no code" and "a loop that iterates 100 times and does nothing". It is thus correct to eliminate the latter to preserve the observable behaviour. However, a loop that never terminates is a very different thing entirely: it says "execution will never progress past this point" and everything afterwards will never be reached. This property is so enshrined in theoretical computer science that any half-decent verification tool will consider what comes after the loop as dead code and not check it. In the newer GCC and Clang the code after a never-ending loop will be marked "unreachable" and be killed as dead code.
So removing a never-ending loop would be quite the big deal indeed.
Technical note: specifically in C and C++ and every language implemented using them, a loop with a counter but no check on the upper bound (eg. "for(i = 0; ; ++i)" ) is very different from the empty loop discussed above. Such a loop would be called "undefined behavior": the program may or may not stop, the world may explode, etc. This is because C and C++ say that overflow has undefined behavior. So this kind of loop does not mean "the programmer intends the control flow to terminate here", but rather "the programmer is playing with fire and it can burn".
[+] [-] beerscout|12 years ago|reply
[+] [-] dman|12 years ago|reply
[+] [-] eliasmacpherson|12 years ago|reply
[+] [-] deletes|12 years ago|reply
[+] [-] aa0|12 years ago|reply
[+] [-] gecko|12 years ago|reply
MSVC is a C++ compiler. It happens to support some C99 (and will support more in VS2013, actually), but that's not its focus. While I, and many other Windows developers, feel that its standard compliance has fallen a bit behind in the last five years or so, Microsoft has made tremendous strides towards fixing that problem lately, and the roadmap (http://blogs.msdn.com/b/somasegar/archive/2013/06/28/1042993...) for full C++11/14 compliance looks good, and seems reasonable. Further, while C++11/14 compliance in MSVC isn't amazing, its compilation speed, and the optimizations it can deliver to its compiled executables, are both top-notch. VC++ generally seems to land between GCC and ICC for most code I write.
Is it perfect? No. Should it support more of C++11 and 14? Yes, and they're working on it. But as much as I wish there were a great C99 compiler on Windows, Microsoft has been open for a very, very long time that that's simply not their focus. Just as I don't assail Apple for Xcode's lousy Python support, I don't see a point in attacking MSVC for not doing C support.