Out of the (C++) loop

[Void Main]

Heh heh, after doing C for so long this is the kind of stuff that prevented me from making any serious headway in C++:
http://www.regdeveloper.co.uk/2006/08/0 ... lus_loops/

[worker201]

Heh, I bet there were jokes like this being circulated when ANSI C came out too.

[ZiaTioN]

LOL...

Sometimes things are done differently for the sake of being different. I disagree with most of the points that were made about the code being wrong. A for() loop allows fore the instantiation, comparison and incrementation all in the decleration of the loop so why worry about porting using iterators? Changing the comparison from < to != could cause issues in itself. < passes for anything that is != and < where != passes for anything that is < and >. Which one is more selective? Which one is more prone to errors? If something funky happened and there was a double iteration or incrementation and the loop bypassed the point where the int was equal you would have an endless loop scenario. Using <, you may experience the same issue at the same point but this discrepencay would only last for a single iteration because at the next check the < would fail because now the int would be != and would be > which the original code tested against and the suggested change does not.

Don't get me started on pre-incrementing either. There are uses for both but to use one over the other just for the sake of cpu cycles is rediculous. If you want an int to be set to 1 before the loops first iteration, set it to one in the instantiation, don't set it to 0 and then pre-increment. Talk about extra cpu cycles.

[JoeDude]

WOW!

Very Technical.

[ZiaTioN]

If you want technical wrap your head around this fact:

Some consider it bad practice to assign variables during instantiation
Ex: int i = 0;

Why you ask? Good question. The way most compilers interpret 0 these days is the exact same way they interpret NULL. So if you were to declare a variable 0 during instantiation and then later do a check for (i == NULL), you would have a false positive. In some minute instances this can cause an issue.

Better practice is to instantiate your variable and then assign it a value before it's first usage.
Ex:

Code: Select all

int i;
blah;
blah
if (i == NULL)
   printf("Huh?\n");

i = 0;
//do something with i


So actually my statement above about setting the variable to 0 during instantiation could be considered bad practice...

[Master of Reality]

If you want technical wrap your head around this fact:

Some consider it bad practice to assign variables during instantiation
Ex: int i = 0;

Why you ask? Good question. The way most compilers interpret 0 these days is the exact same way they interpret NULL. So if you were to declare a variable 0 during instantiation and then later do a check for (i == NULL), you would have a false positive. In some minute instances this can cause an issue.

So actually my statement above about setting the variable to 0 during instantiation could be considered bad practice...

but if we're still talking about instantiating it while declaring it in a for loop declaration it wouldnt matter anyhow.

[JoeDude]

OK, I've read that like 3 times now...I don't get where the difference is...Mind you, I have no formal training, everything I've done to this point has been self taught, so I may be a bit slow on the up take...

OHHHHHHHH never mind I see the process there...your establishing the value and the null seperately...ok got it

[ZiaTioN]

If you want technical wrap your head around this fact:


Some consider it bad practice to assign variables during instantiation
Ex: int i = 0;

Why you ask? Good question. The way most compilers interpret 0 these days is the exact same way they interpret NULL. So if you were to declare a variable 0 during instantiation and then later do a check for (i == NULL), you would have a false positive. In some minute instances this can cause an issue.

So actually my statement above about setting the variable to 0 during instantiation could be considered bad practice...

but if we're still talking about instantiating it while declaring it in a for loop declaration it wouldnt matter anyhow.

Well technically it still could:

Code: Select all

#include <stdio.h>

int main () {
        int i;
        for (; i == (int)NULL; i++) {
                printf("Iteration: %d\n", i);
                if (i==(int)NULL) {
                        printf("I am NULL!\n");
                        break;
                }
        }
        return 1;
}



This code will never execute even a single iteration of the loop because i is not NULL.

Code: Select all

#include <stdio.h>

int main () {
        int i;
        for (i=0; i == (int)NULL; i++) {
                printf("Iteration: %d\n", i);
                if (i==(int)NULL) {
                        printf("I am NULL!\n");
                        break;
                }
        }
        return 1;
}


This code will execute exactly one iteration of the loop because while i=0 i == NULL is true.

Code: Select all

#include <stdio.h>

int main () {
        for (int i=0; i == (int)NULL; i++) {
                printf("Iteration: %d\n", i);
                if (i==(int)NULL) {
                        printf("I am NULL!\n");
                        break;
                }
        }
        return 1;
}


This code will not even compile becuase the C99 standards conflict for the very reason I am outlining here.

instance.c:4: error: ‘for’ loop initial declaration used outside C99 mode

Note* Had to cast NULL to int to quiet warnings... or I could have instantiated i to be int *i.

[JoeDude]

now your just showing off