![]() |
|
Program Flow vs Coding Order - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +--- Thread: Program Flow vs Coding Order (/showthread.php?tid=4443) |
Program Flow vs Coding Order - Pete - 02-02-2026 I started this thread for us to post some snippets that illustrate how coding order trumps program flow in expected results. Steve brought up a good example in regard to sub sorting from : https://qb64phoenix.com/forum/showthread.php?tid=4428&pid=39631#pid39631 Code: (Select All)
Now switch that to... Code: (Select All)
Changing the program flow won't change the outcome. Call FOO: INT or INT: FOO and the results will be the same. It' the flipping of the SUB codes that influence the outcome. The coding order in the first example treats x as an integer, because the sub containing DEFINT was placed before the sub containing the Print statement. The results of Len(x) will be 2 bytes. Switch the subs in the code and x remains an undeclared default single, (so Len(x) will be 4 bytes) even if you call INT first. Now here's one that nailed me decades ago, my first encounter with "Duplicate Definition". Code: (Select All)
So again the program flow seems like it should handle the situation, as the Gosub statement leads us to the Redim of the array, before we print the array value. Ah, but the coding order shows that from top down, we tried to print the value before we dimensioned the array. So the fix is simple, just remember to... Code: (Select All)
So please share other examples where coding order effects outcome, regardless of program flow, in this thread. Pete RE: Program Flow vs Coding Order - SMcNeill - 02-02-2026 Any command that is handled in the preprocess direct queue is subject to this type of problem. Code: (Select All) SUB INITMove that FOO before INIT and that $LET isn't going to work or trigger for you. It works solely on a first come, first serve basis. Other things of similar processing: OPTION BASE 0/1 DEF(any) _DEFINE $CHECKING:ON/OFF $RESIZE:whatever Heck almost any of the metacommands are handled on a top/down flow. Code: (Select All) SUB INITWith the above, you've basically screwed with $CHECKING completely opposite of how you intended. So any of these precompiler type commands work with like this. Beware when moving subs/functions. It's not as simple as it seems. RE: Program Flow vs Coding Order - dano - 02-03-2026 (02-02-2026, 05:34 PM)Pete Wrote:You just solved an issue I was having last week where I was like "NO...this is NOT a duplicate definition !?!". After banging my head against the wall, calling in the drywall crew to fix it, and doing it again - I just gave up. Now I know what was happening there. UGH !!! THANKS! RE: Program Flow vs Coding Order - Pete - 02-03-2026 I'd give you the name of my drywall guy, but he retired 35 years ago when I ran into this same problem. I tried to contact Steve, but his mom said he was in town buying pimple cream to go to the junior prom... alone. Glad it helped! Pete
|