Program Flow vs Coding Order

[Pete]

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...1#pid39631

Code: (Select All)

INT: FOO 

 

SUB INT

    DEFINT A-Z

END SUB



SUB FOO

   PRINT LEN(x)

END SUB 

Now switch that to...

Code: (Select All)

INT: FOO 



SUB FOO

   PRINT LEN(x)

END SUB



SUB INT

    DEFINT A-Z

END SUB 

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)

GoSub pete

Print MyArray(1)

End



pete:

ReDim MyArray(10)

MyArray(1) = 5

Return

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)

ReDim MyArray(0) ' We'll increase this value in the Gosub.

GoSub pete

Print MyArray(1)

End



pete:

ReDim MyArray(10)

MyArray(1) = 5

Return

So please share other examples where coding order effects outcome, regardless of program flow, in this thread.

Pete

[SMcNeill]

Any command that is handled in the preprocess direct queue is subject to this type of problem.

Code: (Select All)

SUB INIT
    $LET whatever = TRUE
END SUB

SUB FOO
    $IF whatever THEN
END SUB

Move 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 INIT
   $CHECKING OFF
END SUB

SUB FOO
   $CHECKING:ON
END SUB

With 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.

[dano]

Code: (Select All)

GoSub pete

Print MyArray(1)

End



pete:

ReDim MyArray(10)

MyArray(1) = 5

Return

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)

ReDim MyArray(0) ' We'll increase this value in the Gosub.

GoSub pete

Print MyArray(1)

End



pete:

ReDim MyArray(10)

MyArray(1) = 5

Return

So please share other examples where coding order effects outcome, regardless of program flow, in this thread.

Pete

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!

[Pete]

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