Calculations in SELECT causes CASE problem

[MrTAToad]

This has been a problem for a little while now - I've just come across this problem again, whereby any calculations in a SELECT statement causes all CASE statements to be ignored for some reason.

For example :

Code (glbasic) Select Expand

SELECT RND(12)
      CASE 0
      index%=SPRITES_TREE1%
     
      CASE 1
      index%=SPRITES_TREE2%
     
      CASE 2
      index%=SPRITES_DEAD_TREE1%
     
      CASE 3
      index%=SPRITES_DEAD_TREE2%
     
      CASE 4
      index%=SPRITES_PALM_TREE%
     
      CASE 5
      index%=SPRITES_BUSH1%
     
      CASE 6
      index%=SPRITES_BUSH2%
     
      CASE 7
      index%=SPRITES_BUSH2%
     
      CASE 8
      index%=SPRITES_CATCUS%
     
      CASE 9
      index%=SPRITES_STUMP%
     
      CASE 10
      index%=SPRITES_BOULDER1%
     
      CASE 11
      index%=SPRITES_BOULDER2%
     
      CASE 12
      index%=SPRITES_BOULDER3%
     
      DEFAULT
      DEBUG "Ooops!"
            ENDSELECT

None of the CASE statements are run, instead the DEFAULT line is used.  Change the SELECT line to a variable and all is okay.

Unfortunately it's due to how the code is converted to C++ :

Code (glbasic) Select Expand

if (FALSE){
ON_DEBUG(0,387);
} else if( (RND(12)) == (0) ){ ON_DEBUG(0,388);
index=SPRITES_TREE1;
ON_DEBUG(0,390);
} else if( (RND(12)) == (1) ){ ON_DEBUG(0,391);
index=SPRITES_TREE2;
ON_DEBUG(0,393);
} else if( (RND(12)) == (2) ){ ON_DEBUG(0,394);
index=SPRITES_DEAD_TREE1;
ON_DEBUG(0,396);
} else if( (RND(12)) == (3) ){ ON_DEBUG(0,397);
index=SPRITES_DEAD_TREE2;
ON_DEBUG(0,399);
} else if( (RND(12)) == (4) ){ ON_DEBUG(0,400);
index=SPRITES_PALM_TREE;
ON_DEBUG(0,402);
} else if( (RND(12)) == (5) ){ ON_DEBUG(0,403);
index=SPRITES_BUSH1;
ON_DEBUG(0,405);
} else if( (RND(12)) == (6) ){ ON_DEBUG(0,406);
index=SPRITES_BUSH2;
ON_DEBUG(0,408);
} else if( (RND(12)) == (7) ){ ON_DEBUG(0,409);
index=SPRITES_BUSH2;
ON_DEBUG(0,411);
} else if( (RND(12)) == (8) ){ ON_DEBUG(0,412);
index=SPRITES_CATCUS;
ON_DEBUG(0,414);
} else if( (RND(12)) == (9) ){ ON_DEBUG(0,415);
index=SPRITES_STUMP;
ON_DEBUG(0,417);
} else if( (RND(12)) == (10) ){ ON_DEBUG(0,418);
index=SPRITES_BOULDER1;
ON_DEBUG(0,420);
} else if( (RND(12)) == (11) ){ ON_DEBUG(0,421);
index=SPRITES_BOULDER2;
ON_DEBUG(0,423);
} else if( (RND(12)) == (12) ){ ON_DEBUG(0,424);
index=SPRITES_BOULDER3;
ON_DEBUG(0,426);
} else { ON_DEBUG(0,427);
DEBUG( __glb_cgstr_5);
ON_DEBUG(0,428);
}

As you can see the RND statement is called for each line, which is a bit different to the original code...  The precompiler would need to be updated so that all the else if statements use some sort of variable instead

[S.O.P.M.]

I wouldn't think it's a bug. I think it's simply not provided that the SELECT command can process a function. But I don't see any problem here - why not get the random number into a variable first and do the SELECT procedure after?

[matchy]

Generally, is there any reason not to do? 

Code (glbasic) Select Expand

LOCAL r = RND(12); SELECT r;...

It's rare for me to have an internal select function but will note it now. I've always casually wondered why it doesn't get converted to switch case but see now. 

There are many times where I've needed, but can't, have multiples eg. CASE 1, 3, 6 to key the code there otherwise it gets split and the code moved to a function. 

[MrTAToad]

The main reason is that it introduces extra inefficiency - defining a variable & assigning a value to it where one isn't always needed.  The compiler should be doing it for us actually - as you can see from my first post, the output doesn't quite match the initial code.

It doesn't just affect random numbers - any calculation in a SELECT statement may have problems.

[spacefractal]

im have newer used calculations and functions in SELECT, since im often have seen issues when im tried that, not just in glbasic. Same with CASE some times.

The most easy to do in this case is simply adding as a varible as matchy did... And then its would been the same.

[kanonet]

But then this should be considered in the help file IMHO. Since its not there, I would call it a bug.

[spacefractal]

yes agreed. Either fixing it, or document it in the help file.