IntyBASIC Read Array Limited, "Foreach"?

[First Spear]

The IntyBASIC manual.txt shows how to read array data with a FOR statement, but it implies that the programmer knows how long the array is, already.

 

What kind of programming needs to be done to read each variable from an array, and stop when there are no more elements? One thing that comes to mind is adding an additional memory value like $FFFF and then test each value and then stop processing when that is hit, but I am not sure that is efficient.

 

How can I mimic "foreach" functionality, or do a FOR statement that stops when the length of the array is reached?

 

 

Thanks.

[intvnut]

The first thing that comes to mind for me is something like this:

.

            FOR #I = VARPTR MyData(0) TO VARPTR MyDataEnd(-1)
                x = PEEK(#I)
            NEXT #I

' ...

MyData:     DATA    1, 2, 3, 4, 5, 6, 7, 8, 9
MyDataEnd:

.

Not the most elegant looking, but seems to generate reasonable code.

 

EDIT: Changed I to #I, because addresses are 16 bits.

Edited September 17, 2017 by intvnut

[First Spear]

Thanks, I will that for tables of data. But what about arrays?

DIM #myArray(2)
for #stepTemp = 0 to #myArray.length     ' That is what I need to understand since the 
                                         ' contents of #myArray will vary from game to game. The length
                                         ' of the array will always be 2 or 6 or 8 or whatever, but the
                                         ' contents will be in RAM and not ROM like in a table. 

Thanks.

 

 

 

 

The first thing that comes to mind for me is something like this:

.

            FOR #I = VARPTR MyData(0) TO VARPTR MyDataEnd(-1)
                x = PEEK(#I)
            NEXT #I

' ...

MyData:     DATA    1, 2, 3, 4, 5, 6, 7, 8, 9
MyDataEnd:

.

Not the most elegant looking, but seems to generate reasonable code.

 

EDIT: Changed I to #I, because addresses are 16 bits.

[+nanochess]

I would use a constant for length and use both for DIM and FOR

[First Spear]

[redacted]

Edited September 18, 2017 by First Spear

[intvnut]

I agree w/ nanochess: If it's the size of a DIM'd array, use a named constant to manage both. I guess my mind went to the array-style access to a compile time ROM data section. That too is an interesting problem, since stuff like level data, music data, graphics data, and so forth can vary in size over time while you're developing.

 

If you really do have a variable length structure in RAM (e.g. an "active objects" table that might grow or shrink over time), then you really do need to store something explicit to indicate the number of valid entries. That is, you can store the length in an 8-bit location, or you can mark inactive slots with a flag, etc.

 

Indicating the length with a sentinel value (the "$FFFF" approach you mentioned) works reasonably well if the test for the sentinel can be combined with something else. In practice, that tends to be tricky and brittle. Otherwise, it can end up being slightly more costly.

[First Spear]

Is there any kind of penalty to be paid for constant re-dim of an array? For example, there are 12 variables I need to set, and for each one I need a temporary “working array” to calculate the variable, and for each calculation the array could be anywhere from 5 to 20 elements in size.

 

Thanks.