10 hours ago
I think I’ve finally lost my mind, but I’m planning to attempt to add support for dynamic nested arrays to QB64PE. I’ve recently managed to get support for static nested arrays working, which has encouraged me to take the next step into the dynamic territory.
If we are to implement dynamic nested arrays - a task I am just beginning (first, I need to clarify the intended behavior) - the syntax for ReDim should look like this:
Imagine a type named "test" containing an integer X, a long array A, and a string array B. If we ReDim an array C(100) of this type, we should then be able to reach further in and call something like: Redim C(0).B(20, 50) as String.
In this case, we would be resizing the nested array B via ReDim. Does this approach seem correct to you? The same logic would apply to _Preserve. For example, Redim _Preserve C(0).B(1, 0) as String would increase the first dimension of the nested array B by one element.
Regarding Erase, I propose extending its functionality so we can clear a specific nested array, such as Erase C(0).B. To keep the implementation consistent with C++ logic (where a nested dynamic array acts similarly to a pointer or a vector member within a struct), I suggest the following:
First, the current implementation of Erase must remain fully functional and work on top-level arrays exactly as it does now. Second, Erase must become context-aware. If I call Erase C (the parent array), the parser must ensure a recursive cleanup of all nested dynamic arrays within every element of C to prevent memory leaks. Third, inside the Type definition, the nested array should be represented by a descriptor. This allows us to use ReDim and _Preserve on a per-element basis, mirroring how one would resize a member vector in C++.
Furthermore, I assume we should also support defining bounds within the Type itself, for example:
Type Test
A(1 to 30) as Long, B(minValue to maxValue) as Long
End Type
I guess so, anyway!
I would like to hear your suggestions and opinions before I start digging deep into the Qb64Pe.bas parser and beyond. As for GET and PUT with these variable nested arrays, direct support might be "impossible" - much like how _Mem "doesn't work" with variable - length strings... So, support is technically possible, just not directly. But that is a task for the very end.
These suggestions seem reasonable to me, but I want to hear your thoughts first.
If we are to implement dynamic nested arrays - a task I am just beginning (first, I need to clarify the intended behavior) - the syntax for ReDim should look like this:
Imagine a type named "test" containing an integer X, a long array A, and a string array B. If we ReDim an array C(100) of this type, we should then be able to reach further in and call something like: Redim C(0).B(20, 50) as String.
In this case, we would be resizing the nested array B via ReDim. Does this approach seem correct to you? The same logic would apply to _Preserve. For example, Redim _Preserve C(0).B(1, 0) as String would increase the first dimension of the nested array B by one element.
Regarding Erase, I propose extending its functionality so we can clear a specific nested array, such as Erase C(0).B. To keep the implementation consistent with C++ logic (where a nested dynamic array acts similarly to a pointer or a vector member within a struct), I suggest the following:
First, the current implementation of Erase must remain fully functional and work on top-level arrays exactly as it does now. Second, Erase must become context-aware. If I call Erase C (the parent array), the parser must ensure a recursive cleanup of all nested dynamic arrays within every element of C to prevent memory leaks. Third, inside the Type definition, the nested array should be represented by a descriptor. This allows us to use ReDim and _Preserve on a per-element basis, mirroring how one would resize a member vector in C++.
Furthermore, I assume we should also support defining bounds within the Type itself, for example:
Type Test
A(1 to 30) as Long, B(minValue to maxValue) as Long
End Type
I guess so, anyway!
I would like to hear your suggestions and opinions before I start digging deep into the Qb64Pe.bas parser and beyond. As for GET and PUT with these variable nested arrays, direct support might be "impossible" - much like how _Mem "doesn't work" with variable - length strings... So, support is technically possible, just not directly. But that is a task for the very end.
These suggestions seem reasonable to me, but I want to hear your thoughts first.