12-07-2022, 10:39 AM
This is one keyword where a lot of people tripped hard, coming from interpreted BASIC. Then after they got comfortable using "dynamic" arrays M$ BASIC PDS offered the "PRESERVE" clause to "REDIM" so that it was abused. Have to watch out for those memory leaks in older programs.
It's OK to use dynamic arrays inside a subprogram as long as its memory is released when the subprogram exits. Sometimes it can't be helped, such as needing to pass an array as parameter for a function, for example that builds a file list. In that case "ERASE" may not be used inside that subprogram, and it may not be used except if the programmer is extra sure at a certain point in the code that the array will no longer be used. The problem is that this programming language makes it so easy to create a static array, which could gobble up RAM, which causes a programmer to expect a dynamic array to behave the same way.
I wish "ERASE" mechanism were unified with those that free "_MEM" variables, font handles, image handles, sound handles and other things needing a specific "FREE" statement. Due to bad experiences in the past with "_FREEFONT" and the like, if I were as good as Galleon was coding in C++ I would fork QB64 to support this, although other things are top priority such as putting "PRING USING" output into a string...
I may or may not know what I'm talking about today.
It's OK to use dynamic arrays inside a subprogram as long as its memory is released when the subprogram exits. Sometimes it can't be helped, such as needing to pass an array as parameter for a function, for example that builds a file list. In that case "ERASE" may not be used inside that subprogram, and it may not be used except if the programmer is extra sure at a certain point in the code that the array will no longer be used. The problem is that this programming language makes it so easy to create a static array, which could gobble up RAM, which causes a programmer to expect a dynamic array to behave the same way.
I wish "ERASE" mechanism were unified with those that free "_MEM" variables, font handles, image handles, sound handles and other things needing a specific "FREE" statement. Due to bad experiences in the past with "_FREEFONT" and the like, if I were as good as Galleon was coding in C++ I would fork QB64 to support this, although other things are top priority such as putting "PRING USING" output into a string...
I may or may not know what I'm talking about today.