04-12-2023, 04:33 PM
It has to be carefully considered, because people have code with "REDIM _PRESERVE ARRAY(1 TO LIMIT) AS STRING * 1e+06" or something absurd like that. Maybe "reset" each new element created while $CHECKING:ON, and don't do it while $CHECKING:OFF? I understand the code in place was done most of all for speed.
I guess the QB64PE developers are confident enough with coding the variable-length strings despite the overhead and the complications. The programmer is the one who decides to waste memory and give up a bit of performance for convenience! But this is also true with Python and other programming languages with libraries "to make it all easier".
However, allowing variable-length string as UDT member sort of defeats the role of _MEM and that's why some people are still afraid of _MEM and steer from it as much as possible. It would be until QB64(PE) could have some OOP attributes, at least subprograms allowed as members of UDT without the schmaltz.
In the future, with _MEM as UDT member, something like a constructor in OOP-land could become mandatory. Otherwise what is the programmer going to do with it if it's going to occupy some memory over thousands of elements? I don't know, maybe instead go like Pascal and have "New()" and "Dispose()" for a specific datatype and a count of them, a lot like "calloc()" in C. I much preferred the old Turbo Pascal way even though it hindered on the OOP concept, which meant it had to be deprecated by the "Object" of v5.5. Yet the "Class" had to be invented later to keep Pascal/Delphi up with C++.
(According to Free Pascal manual, "Objects" were always allocated from the stack, and "Classes" were less limited in memory requirements according to 16-bit mentality.)
Yes I'm rambling again, but the thing is that the decision is expected, to be made at any cost to initialize any new elements "automatically", by some people, although rather few in number that come over directly from QuickBASIC and QBasic and use UDT's.
I guess the QB64PE developers are confident enough with coding the variable-length strings despite the overhead and the complications. The programmer is the one who decides to waste memory and give up a bit of performance for convenience! But this is also true with Python and other programming languages with libraries "to make it all easier".
However, allowing variable-length string as UDT member sort of defeats the role of _MEM and that's why some people are still afraid of _MEM and steer from it as much as possible. It would be until QB64(PE) could have some OOP attributes, at least subprograms allowed as members of UDT without the schmaltz.
In the future, with _MEM as UDT member, something like a constructor in OOP-land could become mandatory. Otherwise what is the programmer going to do with it if it's going to occupy some memory over thousands of elements? I don't know, maybe instead go like Pascal and have "New()" and "Dispose()" for a specific datatype and a count of them, a lot like "calloc()" in C. I much preferred the old Turbo Pascal way even though it hindered on the OOP concept, which meant it had to be deprecated by the "Object" of v5.5. Yet the "Class" had to be invented later to keep Pascal/Delphi up with C++.
(According to Free Pascal manual, "Objects" were always allocated from the stack, and "Classes" were less limited in memory requirements according to 16-bit mentality.)
Yes I'm rambling again, but the thing is that the decision is expected, to be made at any cost to initialize any new elements "automatically", by some people, although rather few in number that come over directly from QuickBASIC and QBasic and use UDT's.