Hi, Robert and dev. Team,
the SWITCH statement is very powerful, but sometimes not comfortable to use (compared to the DO CASE):
FUNCTION ActonChoice(nChoice as LONG) AS VOID
SWITCH nChoice
CASE 0
RETURN
CASE 1
ChoiceOne()
CASE 2
ChoiceTwo()
CASE 3
CASE 4
CASE 5
..........
CASE 100
ChoiceOverFour()
CASE 101
............
CASE 1000
ChoiceOVER()
END SWITCH
My request is if it were possible to simplify in this way:
FUNCTION ActonChoice(nChoice as LONG) AS VOID
SWITCH nChoice
CASE 0
RETURN
CASE 1
ChoiceOne()
CASE 2
ChoiceTwo()
CASE 3 TO 100
ChoiceOverFour()
CASE 101 TO 1000
ChoiceOVER()
END SWITCH
best regards,
Fabrizio
Implementation request for the SWITCH statement
Implementation request for the SWITCH statement
Hi Fabrizio,
Unfortunately this is not supported in any .Net language. In short, the reason is that SWITCH is designed to be very fast, by creating a "jump table", which decides with just one operation, where to make the jump, depending on the value of the SWITCH variable. If you start adding ranges of values, then each of those ranges need to be evaluated (if the value falls inside them), so the jump cannot be done in one operation and the advantage of the SWITCH command is lost.
Theoretically, the compiler could implicitly translate
CASE 3 TO 100
to
CASE 3
CASE 4
CASE 5
CASE 6
....
CASE 100
and emit all that in the IL code, but in this case I guess the generation of the jump table will probably create a huge overhead, so again there is no reason to use SWITCH. In such cases, it's just better to simply use DO CASE (or IF...ELSEIF) instead.
Edit: Although the first answer in this seems to suggest that this functionality has actually been implemented in c# 7.0! Hmm, need to check... https://stackoverflow.com/questions/201 ... one-number
Edit2: Looks like this feature is included in c# 9.0: https://www.infoq.com/news/2020/07/CSha ... -Patterns/
So sooner or later, this can be included in X# as well! So please forget what I said above
I guess it still makes sense to prefer it, compared to DO CASE even in this case, since it still provides compile-time checking for multiple or incorrect type of values etc.
Unfortunately this is not supported in any .Net language. In short, the reason is that SWITCH is designed to be very fast, by creating a "jump table", which decides with just one operation, where to make the jump, depending on the value of the SWITCH variable. If you start adding ranges of values, then each of those ranges need to be evaluated (if the value falls inside them), so the jump cannot be done in one operation and the advantage of the SWITCH command is lost.
Theoretically, the compiler could implicitly translate
CASE 3 TO 100
to
CASE 3
CASE 4
CASE 5
CASE 6
....
CASE 100
and emit all that in the IL code, but in this case I guess the generation of the jump table will probably create a huge overhead, so again there is no reason to use SWITCH. In such cases, it's just better to simply use DO CASE (or IF...ELSEIF) instead.
Edit: Although the first answer in this seems to suggest that this functionality has actually been implemented in c# 7.0! Hmm, need to check... https://stackoverflow.com/questions/201 ... one-number
Edit2: Looks like this feature is included in c# 9.0: https://www.infoq.com/news/2020/07/CSha ... -Patterns/
So sooner or later, this can be included in X# as well! So please forget what I said above
I guess it still makes sense to prefer it, compared to DO CASE even in this case, since it still provides compile-time checking for multiple or incorrect type of values etc.Chris Pyrgas
XSharp Development Team test
chris(at)xsharp.eu
XSharp Development Team test
chris(at)xsharp.eu
Implementation request for the SWITCH statement
Hi Chris,
ok I will use Do Case / If until X # is aligned with C # 9.0
best regard.
Fabrizio
ok I will use Do Case / If until X # is aligned with C # 9.0
best regard.
Fabrizio
Implementation request for the SWITCH statement
Hi Fabrizio,
Well, c# 9.0 is not even released yet
But it should be, in the next few months.
Well, c# 9.0 is not even released yet
But it should be, in the next few months.
Chris Pyrgas
XSharp Development Team test
chris(at)xsharp.eu
XSharp Development Team test
chris(at)xsharp.eu