SELECT with "conditional" CASEs

[ampos]

In the following program, "CASE 2" is never selected. The compiler gives no error also.

So, or a) CASE is failing or b) Compiler should give an error...

Code (glbasic) Select Expand

FOR y=1 TO 20
x=RND(2)
SELECT x
  CASE 0
   DEBUG x
  CASE 1 or 2
   DEBUG x
ENDSELECT
NEXT


[Moebius]

It would be great if this wasn't a 'Compiler Error' so please fix it if you can   

Looking in the temporary C++ files you can see what goes wrong:

Code (glbasic) Select Expand

for (y = 1 ; y<= 20; y++)
{
x=RND(2);

// select:
if (FALSE){

} else if( (x) == (0) ){

DEBUG( x);

} else if( (x) == (1 OR 2) ){

DEBUG( x);
}
}

the second 'else if' should be something like this instead:

Code (glbasic) Select Expand

} else if( (x) == (1) OR (x) == (2) ){

BTW should the OR be there?  Is that a mistake by the compiler (i.e. copying the text from the GLB file), or is it a custom defined operator or something?

Anyway I didn't know this feature had a chance of existing, and it would be great if it did 

[ampos]

Well CASE <2 also works. Not sure if it should or not but works.

[Moebius]

that looks fine - CASE <2 becomes:

Code (glbasic) Select Expand

} else if( (x)<(2) ){

[MrTAToad]

Thats odd - this works fine (as it should) :

Code (glbasic) Select Expand

LOCAL a%

a%=2

SELECT a%
CASE 0
DEBUG "0"

CASE 1 TO 2
DEBUG "1-2"
ENDSELECT

Output : 1-2

Do you have yesterdays update ?

[Moebius]

I just updated to .015 (I think) then... I'll see again now...

[MrTAToad]

If you need values that aren't in consecutive ranges you need seperate CASE statements.  Using OR should generate a syntax error (but doesn't)

[Moebius]

'TO' works nicely actually - I never realised...
Thanks again to Gernot for these features.

Even though OR doesn't work, it COULD work - when the compiler sees:

Code (glbasic) Select Expand

SELECT x
CASE aaa OR bbb
Converting the "aaa OR bbb" to this should work:

Code (glbasic) Select Expand

(x == aaa) OR (x == bbb)

It would be nice to have ORs considering TOs are allowed - they can be useful here.


Perhaps THIS could work someday:   

Code (glbasic) Select Expand

SELECT x
      CASE (0 TO 4) OR (10 TO 14)
            //............
      CASE (5 TO 9) OR > 15 AND < y
           //............
END SELECT

[MrTAToad]

I think it would be better if non sequential values (and thus strings) were separated by a comma, rather than OR

[Moebius]

using OR evaluates to a BOOLEAN, so somewhere down the line, CASE will either see a '0' or a '1', which is perfectly sensible

That makes complete sense in that "1 OR 2" would turn out as a "1".  Didn't realise that before.

I think it would be better if non sequential values (and thus strings) were separated by a comma, rather than OR

Good idea - I agree that it would make more sense as OR is definitely a logical operator, and would be a nice addition.