Arrays inside Types?

[SMcNeill]

@Petr needs to go to the Github, make a branch of the repo, and then push these type of changes upstream so the devs can easily see them and work with them and add them into the language so they'll be here for everyone going forward from now on.

And if he's going to be working on stuff like this regularly (we can hope), then he should join the dev team and come over to Discord where he can kick around things with everyone else and get/share help with whatever development idea he wants to work on and help with next. 

[Petr]

Should I try GitHub? Alright, I’ll give it a shot. I’ve never worked actively through it before, so first I’ll have to figure out how it works. I would definitely like to contribute a few things to QB64PE. I’d use my own solutions, but of course, I would submit them to the GitHub community for approval first.

However, I’d need to know what to watch out for, what the strict requirements are, and what criteria must be met for anything to be merged. I don't want to go against the rules.

I'm happy to give this collaboration a try.

@Jack – I have provided a detailed response.

[Jack]

@Petr
thanks a million for the detailed explanation https://qb64phoenix.com/forum/showthread...1#pid40461

[Petr]

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.

[madscijr]

While you're at it, how about associative arrays (dictionaries)? 

[CookieOscar]

My 0.000002 cents for what it's worth:

...
Redim C(0).B(20, 50) as String
...

I assume this only redims B() in the 0 indexed element of C(), and not any other B() array from other existing C() elements?
Cool!

So, what about:
Redim C().B(20, 50) as String
or even:
Redim C.B(20, 50) as String

Could that redim ALL B() arrays of ALL existing elements of C()?
Or is that taking it too far?

PS: I think I've never had the need to have an array inside an array/UDT inside an UDT like that before though. But very cool if all this would become possible (as long as there is no additional overhead in the underlying C++ code when not used -- especially speed wise)! The most complex I ever had the need for was a dynamic array (with fixed number of dimensions) of a build-in type inside an UDT.

PSS: Make sure you touch grass from time to time. Loosing your mind is no bueno