The Mystery of the Newb's for Loop.
Cerpin Taxt

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

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

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

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

Audric

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

Albin Engström

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

:o

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

Albin Engström

I believe it's a matter of taste :).

Ceagon Xylas

Guess so hehe

Evert

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
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 ;)

Evert

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
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{
3 int result = x;
4
5 switch(x)
6 {
7 case 100:
8 result *= 13;
9 break;
10 
11 case 102:
12 result *= 10;
13 /* Fall through */
14 
15 case 103:
16 result += 11;
17 break;
18 
19 case 104:
20 case 106:
21 result *= result;
22 break;
23 
24 default:
25 result = 0;
26 }
27 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

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

Audric

I thought computed goto was a DJGPPism? great anyway.

Thread #589991. Printed from Allegro.cc