I'm going to go with this is a common misconception then. I've heard it a few times before, and for instance this article:
c - Example of a while loop that cannot be replaced by a for loop - Stack Overflow
Someone clearly says "Most compilers actually expand for loops to while loops", which doesn't really leave it open for interpretation. This doesn't mean that what he said is correct, but do you have supporting evidence?
Supporting evidence would be that compilers usually translate to some intermediate language and work with that, so any "expand some type of loop to another type of loop" would be in terms of that intermediate language, not C, and it may just involve goto or an equivalent, not specific loop constructs.Originally Posted by Epy
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Thanks Epy, that cleared it up.
I don't know why I even brought up the thing about the for loops. Pretty much all loops end up using the jump if something instruction (jne, jle, whatever), right?
Edit: point is, it basically ends up being the same machine code in the end, how can for loops be more efficient than while loops? There's always some sort of conditional that's executed every iteration of the loop.
A for-loop communicates intent. Both to other programmers and to the compiler itself. It only takes 10 minutes of fooling with the compiler to see that in some cases it generates different code depending how you write a loop. Whether this is just happenstance or indicates something deliberate inside the compiler, I don't know. It's true that everything compiles to some intermediate format which is where most optimizations happen, there's nothing that says the compiler can't take advantage of additional information if it wants to.
For instance, in some big complex while-loop it may be unclear which variable plays the role of indexer. In a for-loop it is usually very obvious which variable is the indexer.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Wow. That is very scary stuff. You should complain to someone.... there are enough plain WRONG points there.
Heh - I remember my supervisor at university saying that to me too. Well, not "never ever ever", but "break and continue are bad!". I asked him why, he said that it is difficult to formally prove correctness of a loop with breaks/continues. I don't know if that's widely true or if it was just true of the particular methods he was using.
I suppose then that "never, ever, ever use break or continue" might be good advice if you were working on a safety critical system where code needed to be proven.
"Never ever ever use goto", I'll stand by
Most normal uses of break/continue can easily be rewritten to not use them. They're meant to allow you to write clearer code, not to enable you to do things you couldn't otherwise do. There are probably cases where break/continue is the only way to accomplish a certain control flow, but I can't imagine them, and it's usually possible to transform a piece of code that uses them into a piece of code that doesn't.
For instance, a loop like this:
Can be replaced with this:Code:for (...) { foo(); if (bar()) break; baz(); }
It's inefficient, more difficult to read, but it does not use break. But I'd question the sanity of somebody who told me the second loop is easier to analyze than the first.Code:bool fBar = false; for (...) { if (!fBar) { foo(); if (bar()) fBar = true; else baz(); } }
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Your replacement isn't correct, brewbuck, as it doesn't terminate the loop. You probably intended something like
Code:bool fBar = false; for (!fBar && ...) { foo(); if (bar()) fBar = true; else baz(); }
All 1 to 7 are all very wrong. No surprise there, as that's the whole reason Tclausex posted them.
1, 2, 3, and 5 can be disproven using an appropriate code sample.
4 Disagrees with a decent percentage of standard library functions.
6 can be disproved using an appropriate compiler. Alternatively one can take the stance that for is not more efficient than do..while because they are not interchangeable.
7 If I catch anyone avoiding an appropriate use of break and instead inserting a dumb flag variable then they get a flogging.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
To be perfectly fair, most schools start the basic programming with Java.
We have to take multiple C classes before we can take upper level Programming classes that include other languages. There is an intro to OOP with Java but you have to take the first C course first. I'm glad it's this way at my uni.
Now now I do agree, when I said "start out with java" I meant as the first basic intro to programming class.
Some schools I've seen it goes
Intro (java)
Intermed (java)
Data Struct (C)
Large Programs (Java)
Intro to Computing Systems (Assembly)
And they hit other langs, like VHDL, MATLAB, SCHEME, etc during the progress.
Appalling that CS students are even exposed to MATLAB. Fortran is a mans language when it comes to numerical computing.