The Mystery of the Newb's for Loop.

The Mystery of the Newb's for Loop.

Cerpin Taxt

Member #8,304

February 2007

Messing around yesterday, I decided to make my first 'game' (essentially just a dot moved by the player to avoid other dots). Anyways, I used a for loop to have it create and update new enemies whenever appropriate.

            if( iEnemy == 1 )   //Checks to see if it's time for enemies to exist.
            {
                for( iRe2 = 0 ; iRe2 == n; ++iRe2)  //Runs through all enemy coordinates.
                {
                    if( mouse_x > iEnemyX[iRe2] ) ++iEnemyX[iRe2];
                    if( mouse_x < iEnemyX[iRe2] ) --iEnemyX[iRe2];
                    if( mouse_y > iEnemyY[iRe2] ) ++iEnemyY[iRe2];
                    if( mouse_y < iEnemyY[iRe2] ) --iEnemyY[iRe2];

                    circle( buffer, iEnemyX[iRe2], iEnemyY[iRe2], 5, makecol( 255, 0, 0 )); //Draws all enemies.
                }
            }

I know for a fact that the issue is with the for loop, and I can comment it out and everthing works fine. Once.

The integer 'n' is increased whenever a new enemy should be added. In my head, this loop should create and update enemies as necessary, but as it is (without commenting anything out ) it seems to keep anything from happening. No enemies are created.

If anyone could help me out, that'd be great.

Audric

Member #907

January 2001

The second term of for() is the required condition to run the body {}. As soon as it evaluates to false, the body is skipped and the program continues.

You probably want iRe2<n or iRe2<=n

Cerpin Taxt

Member #8,304

February 2007

Well I feel dumb. I thought it was the exit condition.

Works perfectly. All thanks to the magic of basic knowledge.

Audric

Member #907

January 2001

Yeah, it's the "positive" condition to meet, so it's consistent with while()

Albin Engström

Member #8,110

December 2006

I've always hated "for" loops, they're just while loops with some inbuilt comfortable extra stuff... but then again, that's what it all is..

Ceagon Xylas

Member #5,495

February 2005

But for loops are amazing! They're like using switch() && case rather than a bunch of if conditions.

Albin Engström

Member #8,110

December 2006

I believe it's a matter of taste .

Ceagon Xylas

Member #5,495

February 2005

Guess so hehe

Evert

Member #794

November 2000

You don't really appreciate the comfort of C for loops until you've had to use FORTRAN DO loops. Personally I've lately become a big fan of Perl's foreach loop.

Thomas Fjellstrom

Member #476

June 2000

Quote:

Personally I've lately become a big fan of Perl's foreach loop.

And the "foreach" style is mostly dpereciated. the for loop does the same thing. one keyword, multiple syntaxes

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Evert

Member #794

November 2000

You mean I can write "for" instead of "foreach"? I know, but I find "foreach" easier to read when I want a "foreach" loop. I don't mind typing the extra four characters at all, unlike Larry (according to my llama).

TeamTerradactyl

Member #7,733

September 2006

Ceagon Xylas said:

But for loops are amazing! They're like using switch() && case rather than a bunch of if conditions.

On the note of "switch()" statements, I learned in my class that they can actually be more optimized than a bunch of if..then()'s!

Using gcc/g++, if you look at (and understand) the disassembled code for your program, it actually tweaks your code to use a lookup table if you have a lot of case... conditions:

Example 1

1int switch_example(int x)
2{
int result = x;

switch(x)
{
  case 100:
    result *= 13;
    break;
10 
  case 102:
    result *= 10;
    /* Fall through */
14 
  case 103:
    result += 11;
    break;
18 
  case 104:
  case 106:
    result *= result;
    break;
23 
  default:
    result = 0;
}
return result;
28}

...gets translated into...

1/* Next line is not legal C */
2code *jumpTable[7] = {
3  loc_A, loc_def, loc_B, loc_C,
4  loc_D, loc_def, loc_D
5};
6 
7int switch_example_implicit(int x)
8{
9  unsigned temp = x - 100;     // <-- The 'unsigned' is an important factor here
10  int result = x;
11 
12  if (temp > 6)
13    goto loc_def;
14 
15  /* This goto is not local C */
16  goto jumpTable[temp];
17 
18  loc_A:  /* case 100 */
19    result *= 13;
20    goto done;
21 
22  loc_B:  /* case 102 */
23    result *= 10;
24    /* Fall through */
25 
26  loc_C:  /* case 103 */
27    result += 11;
28    goto done;
29 
30  loc_D:  /* cases 104, 106 */
31    result *= result;
32    goto done;
33 
34  loc_def:
35    result = 0;
36 
37  done:
38    return result;
39}

EDIT: Understand, that this isn't assembly that you're looking at, but rather a pseudo-code written in a "kinda" C format so those of a.cc who don't natively speak ASM could figure out what's going on.

So if you put in a number < 100, it overflows (underflows?) to become a very large value, which is > 6 (which is how many "case:" statements you have in your code). Also, notice that since there is no "101" or "105", they are still accounted-for in the "jumpTable" (by putting in locations of "loc_def" -- which is at the end of the switch() statement). It's that "default:" that turns everything else into "result = 0", so that's where it jumps to.

Anyway, that's just something I picked up from one of these courses I'm taking. As I understand it, unless you only have one or two "...else if..."s in your code, a switch statement is more optimal to have.

Thomas Fjellstrom

Member #476

June 2000

If you use &&label in the jumptable, and goto **table[index];, it should work in GCC.

Audric

Member #907

January 2001

I thought computed goto was a DJGPPism? great anyway.