Arrays/STRUCT

[Carl Gundel]

Feb 21, 2021 21:33:05 GMT -5 Brandon Parker said:

Yeah, but ... maybe it was designed the way it is implemented. Only Carl would be able to confirm.

Either way, you can always accomplish what you are after if you post what you want to achieve.


{:0)

Brandon Parker

Unless someone has discovered a bug (did I miss something?) then it works as intended. 

[Chris Iverson]

I would argue that this example of Walt's is a bug, and at least is unexpected behavior.

B$ = FN.ReDim$()

PRINT tStr.A.struct
PRINT B$, A(0,0)     '<--- Compile error: A is single dimension

WAIT
END

'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------

FUNCTION FN.ReDim$()

STRUCT tStr, A AS LONG, B AS SHORT

DIM A(0, 1)
A(0, 0) = 1
A(0, 1) = 1

tStr.A.struct = 255

FN.ReDim$ = "Ok"
END FUNCTION

By the time the offending line would execute, the array would indeed be dimensioned properly, but it throws a compile-time error because the compiler doesn't "see" a dim statement before that line.

[Brandon Parker]

Feb 21, 2021 15:00:33 GMT -5 tsh73 said:

I think it most likely has to do with the fact that single-dimension arrays are automatically made available up to element number 10 whereas double-dimension arrays are not.

Double dimensioned, undimmed, works OK
a(3,1)=7
print a(3,0)
print a(3,1)

Actually. More strange thing happens.

With single dimensioned array you get a(0)..a(10) instantly - you request it's value - say print - and get 0

If you request value from 2d undimmed array, say
print a(5,1)
you get "array a() is 'one' dimensional" error
But if you assign to 2d undimmed array, say
a(5,0)=7
after that you can use a(0,0) to a(10,10).

Also
DIM not have tobe executed at all to work (that's strange)

Anatoly,
Change your array name from b() to ba() (or something with more letters). It seems like something is going on there with the single "b" as the name of the array.

That being said, I can definitely see that things are not always dealt with equally.

So the difference is this which works correctly ...
Call setupArray

myArray(0,0) = 12

Print myArray(20,20)

myArray(20,20) = 20
Print myArray(20,20)
End

Sub setupArray
   Dim myArray(20,20)
End Sub

compared to this which does not work although one would presume it would from a program flow perspective ...
Call setupArray

'myArray(0,0) = 12

Print myArray(20,20)

'myArray(20,20) = 20
Print myArray(20,20)
End

Sub setupArray
   Dim myArray(20,20)
   myArray(0,0) = 12
   myArray(20,20) = 20
End Sub

Maybe this is something that we just have not stumbled across before...? I mean, I can't say that I would have since 2009 because I have not been using the standard method of using arrays in LB since I created my Dynamic Array library. It's only single-dimension also, so maybe I just have not messed with double-dimensioned arrays enough to catch the difference there; of course, I always just dimension the one/two double-dimensioned arrays I have needed at the start of a program anyway.


{:0)

Brandon Parker

[Brandon Parker]

And, another kink to the chain...

It looks like the compiler/runtime actually "sees" the double-dimensioned array and makes it available even before its instantiation...
So, you can store values into it up to the dimensioned elements (or...to be dimensioned anyway because it has no been done yet), but that is wiped out when the "Dim" statement is executed (kind of expected there...).
Print "Prior to the instantiation of myArray(x,y)"
myArray(19,19) = 19
Print "Element 19,19 - ";myArray(19,19)

Call setupArray

Print "After the instantiation of myArray(x,y)"
Print "Element 19,19 - ";myArray(19,19)
Print "Element 20,20 - ";myArray(20,20)
End

Sub setupArray
   Dim myArray(20,20)
   'Put this back in and you will see element 19,19 be repopulated
   'as expected
   'myArray(19,19) = 19
   myArray(20,20) = 20
End Sub

This is super-interesting as I would have expected this to completely fail.


{:0)

Brandon Parker

[Carl Gundel]

Feb 22, 2021 16:44:40 GMT -5 Brandon Parker said:

And, another kink to the chain...

It looks like the compiler/runtime actually "sees" the double-dimensioned array and makes it available even before its instantiation...
So, you can store values into it up to the dimensioned elements (or...to be dimensioned anyway because it has no been done yet), but that is wiped out when the "Dim" statement is executed (kind of expected there...).
Print "Prior to the instantiation of myArray(x,y)"
myArray(19,19) = 19
Print "Element 19,19 - ";myArray(19,19)

Call setupArray

Print "After the instantiation of myArray(x,y)"
Print "Element 19,19 - ";myArray(19,19)
Print "Element 20,20 - ";myArray(20,20)
End

Sub setupArray
   Dim myArray(20,20)
   'Put this back in and you will see element 19,19 be repopulated
   'as expected
   'myArray(19,19) = 19
   myArray(20,20) = 20
End Sub

This is super-interesting as I would have expected this to completely fail.

Not sure how that's a kink.  Arrays are supposed to be dimensioned at the beginning of a program.

[Carl Gundel]

Feb 22, 2021 16:08:03 GMT -5 Chris Iverson said:

By the time the offending line would execute, the array would indeed be dimensioned properly, but it throws a compile-time error because the compiler doesn't "see" a dim statement before that line.

DIM is meant to be used before an array is used in code.

[Chris Iverson]

Which is understandable, but I was operating on the assumption that that would be a runtime restriction, not compile-time.

That is, as long as the code executes a DIM statement before using the array, it would be fine. That's what I would expect, but that's not the case.

It really is a compile-time restriction. It's like declaring functions in C/C++. Even if it is declared, if it's not declared to the compiler before it's seen to be used by the compiler, it doesn't work.


I never really ran into this issue before, because I usually dimension arrays either at the very beginning of code, or the beginning of the block it's used, but I can still understand some confusion about this.

[Carl Gundel]

Feb 22, 2021 19:22:37 GMT -5 Chris Iverson said:

Which is understandable, but I was operating on the assumption that that would be a runtime restriction, not compile-time.

That is, as long as the code executes a DIM statement before using the array, it would be fine. That's what I would expect, but that's not the case.

It really is a compile-time restriction. It's like declaring functions in C/C++. Even if it is declared, if it's not declared to the compiler before it's seen to be used by the compiler, it doesn't work.


I never really ran into this issue before, because I usually dimension arrays either at the very beginning of code, or the beginning of the block it's used, but I can still understand some confusion about this.

Understood.  It isn't an interpreter. 

[Rod]

Don’t want to prolong this but there is a fine point being missed. There is a distinction between reading and setting an array. As Brandon shows just setting the array is enough to establish it without DIM. Remember we can have 0_9 arrays both single and multi dimension just by setting them. BUT reading them as Walt shows, is not enough to establish them.

So, instead of keeping all those rules in your head it is far far simpler to DIM them right up front. That also helps affirm that the arrays are Global by design.

[Brandon Parker]

Feb 23, 2021 3:10:27 GMT -5 Rod said:

Remember we can have 0_9 arrays both single and multi dimension just by setting them.

The only problem is that the help file specifically states the double-dimensioned arrays must be instantiated with the "Dim" statement. And, it is really 0 - 10 that are available...

From the helpfile ...

Double dimensioned arrays must always be dimensioned with the DIM statement before use.

DIM scores$(20, 10)

{:0)

Brandon Parker

[Rod]

Look under DIM, that's where I got the quote from. The help file needs tweaked in places.

a(1)=1
b(1,2)=2
b(10,10)=3
'b(11,11)=4
print a(1)
print b(1,2)
print b(10,10)



I think the array handling has changed a little. I always thought that you needed to dim above 11 elements So a(11) undimmed would give an error. I always thought that two dimensioned arrays always needed declared. But that seems to have changed.

"DIM sets the maximum size of an array. Any array can be dimensioned to have as many elements as memory allows. If an array is not DIMensioned explicitly, then the array will be limited to 11 elements, 0 to 10. Non DIMensioned double subscript arrays will be limited to 100 elements 0 to 9 by 0 to 9. The DIM statement can be followed by a list of arrays to be dimensioned, separated by commas."

So now you can have a(10,10) without declaration or dimming, but you must "set" it for it to exist.

As Anatoly has shown if it is not "set" ie used, then it does not exist. So back to the original problem. If you have not "declared" an array by either dimming it or setting one element then it does not exist and the compiler will trip up.