SELECT CASES ??? - Printable Version +- QB64 Phoenix Edition (https://staging.qb64phoenix.com) +-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2) +--- Thread: SELECT CASES ??? (/showthread.php?tid=978) |
SELECT CASES ??? - Pete - 10-16-2022 We have SELECT CASE and SELECT EVERYCASE, but does any language make use of SELECT CASES? Example. Let's say I have two coordinates y, and x I can do... Code: (Select All) SELECT CASE y But wouldn't it be cool to just code it as: Code: (Select All) SELECT CASES y, X Pete RE: SELECT CASES ??? - SMcNeill - 10-16-2022 Yucky yuck yuck! Look close at your code samples. Count the conditions you check against for point (-1, -1)... The first does 3 checks for y, 3 checks for x. The second does 9 checks for y, 9 checks for x. 6 conditional checks vs 18.. How much slower is the multiple select cases going to be?? Yucky yuck yuck! To highlight the difference, the first method you posted ADDs the number of possibilities together for how many conditions it may have to check against. The second method that you proposed, has to MULTIPLY the number of possibilities together. With 10 choices for X and 10 choices for Y, the first method has to make a maximum of 20 condition checks -- while the second could be making up to 100... With 10 choices for X, Y, and Z, the first method has to make a max of 30 condition checks -- while the second would be making up to 1000... Do you *really* want to add that type of overhead to your program? RE: SELECT CASES ??? - James D Jarvis - 10-16-2022 It would be cool if we had that. RE: SELECT CASES ??? - Pete - 10-16-2022 I agree it is certainly not set up for speed, but outside of gaming there are uses that milliseconds don't matter. It's easier to code for variable relationships, but yes, you'd have some explaining to do as to when and when not to use it. What I was mostly curious about is if any other coding languages allow for case relationships. Obviously it C/C++ does not, this would be a pain to incorporate into QB64. Pete RE: SELECT CASES ??? - SMcNeill - 10-16-2022 (10-16-2022, 08:49 PM)James D Jarvis Wrote: It would be cool if we had that. Why? You're not saving typing, and you're not going to be as efficient or fast with your program by trying to use such syntax. What possible benefit could it offer at all? If someone wants to work up such a syntax, I'd at least suggest making it somewhat simpler such as: Code: (Select All) SELECT CASES y, x Of course, that's not a whole lot different than what we have currently, so I doubt it's worth the effort to implement in the long run. Honestly, it seems to me that if one prefers that type of syntax, they'd be better off just writing IF statements. IF y > 0 AND x < 0... IF y > 0 AND x = 0... IF y > 0 and x > 0... RE: SELECT CASES ??? - Pete - 10-16-2022 Two votes for cool, 1 vote yuck. Cool wins. When can we expect the roll out??? Pete RE: SELECT CASES ??? - SMcNeill - 10-16-2022 (10-16-2022, 09:12 PM)Pete Wrote: Two votes for cool, 1 vote yuck. Cool wins. When can we expect the roll out??? I dunno. How quick can you push a pull request with the changes you've implemented for this into the repo, so we can reject them? I imagine the roll out would probably be two days after never, after that! Kidding aside, I honestly don't think any developer would waste their time ever typing to adopt such a syntax into the language. All we do with SELECT CASE is translate the SELECT CASES into IF.. THEN.. code already. For example here's a simple SELECT CASE and it's translated code: Code: (Select All) Select Case x Code: (Select All) if (((*__SINGLE_X<((float)( 0 ))))||new_error){ Our SELECT CASE basic code gets translated into IF-THEN c code, when all is said and done. As I mentioned above, if one *really* likes such a syntax as you showcased, why not just use IF-THEN directly and skip that step of QB64 having to translate from SELECT CASE to IF for you. RE: SELECT CASES ??? - Kernelpanic - 10-16-2022 There are coincidences! I had a problem today with calling a function in "Select ... Case". There are no problems with a procedure, but it didn't work with the function. Maybe anyone know why? Code: (Select All) Declare Sub Eingabe() RE: SELECT CASES ??? - SMcNeill - 10-16-2022 If it's a FUNCTION, then doesn't it need a return variable associated with it? x = SatzLesen (or such) RE: SELECT CASES ??? - Pete - 10-16-2022 (10-16-2022, 09:57 PM)SMcNeill Wrote: If it's a FUNCTION, then doesn't it need a return variable associated with it? That's the first thing you've been right about in the last 10 minutes. Either that or something like... Code: (Select All) PRINT SatzLesen Pete |