Thread: Why new programming students aren't fairing well.

Originally Posted by Epy

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

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.

Originally Posted by smokeyangel

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.

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:

Code:

for (...)
{
    foo();
    if (bar())
        break;
    baz();
}

Can be replaced with this:

Code:

bool fBar = false;
for (...)
{
    if (!fBar)
    {
        foo();
        if (bar())
            fBar = true;
        else
            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.

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.