+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: suggestion: change to _MEMFREE (/showthread.php?tid=1263)
suggestion: change to _MEMFREE - OldMoses - 12-11-2022
While working with _MEM blocks and freeing them, it occurred to me that perhaps it would be a useful alteration to have _MEMFREE work similar to the new DIM syntax, where one can:
DIM AS INTEGER a, b, c, etc.
Where instead of the required syntax following:
_MEMFREE m
_MEMFREE m2
_MEMFREE m3
One could do:
_MEMFREE m, m2, m3
Would there be any interest in such a change, or would that be too difficult of an implementation?
RE: suggestion: change to _MEMFREE - mnrvovrfc - 12-11-2022
Good idea! "ERASE" supports multiple array variables. But it would have to be done with "_FREEFONT", "_FREEIMAGE" and "_SNDCLOSE" as well.
But don't "_MEM" blocks have to be freed in a specific order, to prevent memory leak? The static UDT variable (ie. what is needed before "_MEM" function, "_MEMNEW" etc. is used) would take up space anyway so it shouldn't matter.
RE: suggestion: change to _MEMFREE - OldMoses - 12-11-2022
(12-11-2022, 01:03 PM)mnrvovrfc Wrote: But don't "_MEM" blocks have to be freed in a specific order, to prevent memory leak? The static UDT variable (ie. what is needed before "_MEM" function, "_MEMNEW" etc. is used) would take up space anyway so it shouldn't matter.True, I assume it wouldn't matter to memory usage, since one has already created the variable/array that one is pointing to.
I suppose a multiple _MEMFREE could work like a multiple NEXT, where you would still be responsible for the order of the variable, if that's important. I always assumed that you could free a _MEM whenever you were done with it, and that it was more a thing of releasing the _MEM pointer variable. I use _MEM like a little old lady drives a car, without understanding its internal combustion principles, so I'm ill equipped to expound on it more.
I was thinking in terms of reduced typing rather than memory management.
RE: suggestion: change to _MEMFREE - SMcNeill - 12-11-2022
_MEM doesn't care what order you free your memory in, just so long as you free them. And even then, it's really only absolutely necessary when you use _MEMNEW to create a new block of memory. All the rest of the time, your _MEM variable is just being a pointer to where something already exists.
For example, _MEMIMAGE creates a pointer which lets you access the memory of an image. _MEMFREE won't make that image go away; at most it'll just free up the mem pointer which points to it. (And you can just reuse that pointer again in the future, with no real worries over it.)
m = _MEM(array()) <-- Same thing. Nothing more than a pointer to where your array() is stored in memory. Freeing that mem only frees the pointer. The array stays just like always, unless you CLEAR/ERASE or do something else with it such as exiting the SUB/FUNCTION it was in.
But when it comes to _MEMNEW, that's when you HAVE to call _MEMFREE. You allocated a chunk of memory for a block to use, the mem variable is the only pointer which points to that block, and it's the only way you can free that memory. *ALWAYS* free _MEMNEW blocks when you're done with them -- and you don't have to worry about any order such as "free m1 first, before m2, before m3..."
Think of them much like opening a file.
DIM m as _MEM <==> OPEN file$ FOR BINARY AS #m
_FREEMEM m <==> CLOSE m
Just like CLOSE doesn't care what order you close your files in, _FREEMEM doesn't care either. Free them when you get done with them -- especially if they're _MEMNEW blocks.
RE: suggestion: change to _MEMFREE - Pete - 12-11-2022
(12-11-2022, 12:43 PM)OldMoses Wrote: While working with _MEM blocks and freeing them, it occurred to me that perhaps it would be a useful alteration to have _MEMFREE work similar to the new DIM syntax, where one can:
DIM AS INTEGER a, b, c, etc.
Where instead of the required syntax following:
_MEMFREE m
_MEMFREE m2
_MEMFREE m3
One could do:
_MEMFREE m, m2, m3
Would there be any interest in such a change, or would that be too difficult of an implementation?
But then I want...
_CLEAR a, b, c, e
Instead of...
a = 0
b = 0
c = 0
e = 0
Complicated by CLEAR being backwards compatible with comma deliminators for memory, which is ignored in QB64; (e.g. CLEAR , , 2000). So _CLEAR
"It's always something..."
In other news..
+ 1 for
"DO: LOOP: DO: LOOP
sha_na_na_na_na_na_na_na_na_na:"
Pete
PS Don't be surprised if I -2 you later... when I can't that jingle out of my head!
RE: suggestion: change to _MEMFREE - OldMoses - 12-11-2022
(12-11-2022, 05:52 PM)Pete Wrote: PS Don't be surprised if I -2 you later... when I can't that jingle out of my head!
It's been stuck in mine for several hours now...