however I don't actually think that makes much of a difference for QB64 because all of the variables are allocated at runtime anyway. I can't say I see the reasons for that choice, but it is how it is (Compile a program and then take a lot inside of ./internal/temp/maindata.txt).
Yes. I think that it is to support VARSEG/DEF SEG. In my opinion, this allocation mechanism is one of the primary things keeping QB64 from being as efficient as it could be. I understand that it is good to support VARSEG/DEF SEG, but most programs don't use it.
All variables are still set to zero after being allocated though, so in that case it would be useful to be able to set their value at that point instead of having to set them again later.
True. That way, you'll get 1 assignment instead of 2.
In that case, some sort of _UNINITIALIZED keyword might be useful. However, this would be dangerous, and would need to be used with care.
I haven't actually looked into how DATA works in QB64. I generally avoided it in QBASIC, and I continue to avoid it in QB64. All I know is that it involves linking an object file into the program.
As it is, you can use DECLARE LIBRARY:
int32 test_array[2][2] = { {0,1}, {-1,0} };
uptrszint getTestArray(void) {return (uptrszint) test_array;}DECLARE LIBRARY "delme"
FUNCTION getTestArray~%& ()
END DECLARE
DIM m AS _MEM: m = _MEM(getTestArray, 2 * 2 * 4)
DIM i AS LONG
FOR i = 0 TO 3
PRINT _MEMGET(m, m.OFFSET + i * 4, LONG)
NEXT
_MEMFREE m
END
To bobtheunplayer:
Please keep in mind that, while in C/C++, you specify the number of elements, in BASIC, you specify the upperbound:
int array[2][2]; // 4 elements
DIM array(2, 2) AS LONG ' 9 elements
This is a good reason for explicitly specifying "0 TO ", to remind yourself that it is the upperbound:
DIM array(0 TO 2, 0 TO 2) AS LONG
Also, C/C++ multidimensional arrays are "row major", whereas BASIC multidimensional arrays are "column major".
Regards,
Michael
