QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: romichess on March 25, 2020, 09:22:10 pm
-
What if the code is written like so:
SELECT CASE
CASE 0
sub0 par1
CASE 1
sub1 par1
CASE 2
sub2 par1
...
END SELECT
Will the C++ compiler produce jump tables?
-
You can check the c++ result by opening internal/temp/main.txt after the IDE gives you an OK in the status bar.
And no, the answer is no.
A select case block is a glorified (and very convenient) long IF block.
-
You can check the c++ result by opening internal/temp/main.txt after the IDE gives you an OK in the status bar.
And no, the answer is no.
A select case block is a glorified (and very convenient) long IF block.
Thanks for the answer. That is very sad for performance. My chess program is going to run really slow. With a few performance enhancements QB64 could become a serious production language. That is a shame that it is not because I really like the Basic syntax.
-
It's BASIC. If constructs from other languages get thrown in then it's not BASIC any longer.
-
You could write your code, look in main.txt in the temp folder, and then manually swap in a switch case block, if you really needed to, before recompiling.
-
It's BASIC. If constructs from other languages get thrown in then it's not BASIC any longer.
But but but a jump table can be created from a SELECT CASE construct without the basic coder even being aware. There would be absolutely no change to the basic language itself. Sorry if I was unclear about that.
-
But but but a jump table can be created from a SELECT CASE construct without the basic coder even being aware. There would be absolutely no change to the basic language itself. Sorry if I was unclear about that.
Ah, I see, yes it was not clear to me.
-
If Speed was a really big deal, you can like Steve Says, go into the Main.txt and edit the C++ code directly and remove some of the over head. There are a lot of IF\THENs in there dedicated just to watching for EXIT stuff. All those extra lines take precious cycles to process. As long as you have no errors in the Computers decision tree you can add $CHECKING OFF to remove some of that over head and speed that code up a bit.
Don't forget that BASIC isn't exactly a speed language, and CHESS is a very logic based game. So there will have to be compromises made. Just think in terms of 1980s era home computers. Chess was a very slow game back then.
Give the Computer a time limit for its "Thought" process and have it choose the best move it was able to get to in that time. and you can have various difficulty setting based on that 'feature'! and the move process would be based on a recursive routine that assigns a score to each move and the recursion that scored the highest at the Time Limit would be used. Very similar to A+ path finding but instead of the lowest move-cost value your using the highest move-payoff value!.
Although I think you already know that... swear thats been touched on on another topic or over in on the Discord channel.
"The worlds dumbest chess computers will play the fastest game ever played, while the worlds greatest chess computers would play the slowest game ever played!" or something like that.
-
If the cases are a sequence of numbers, 0, 1, 2, ...., n, then for the application in question, how large would n be?
Would each case have it's own sub, or would some cases share the same sub?
I am thinking of some sort of binary search could be implemented, rather than linearly starting at 0 and testing for a match with each possible integer up to n.
-
If the cases are a sequence of numbers, 0, 1, 2, ...., n, then for the application in question, how large would n be?
Would each case have it's own sub, or would some cases share the same sub?
I am thinking of some sort of binary search could be implemented, rather than linearly starting at 0 and testing for a match with each possible integer up to n.
Steve clued me in on the right alternative in another thread, ON GOTO/GOSUB.