suggestion: change to _MEMFREE

[OldMoses]

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?

[mnrvovrfc]

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.

[OldMoses]

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.

[SMcNeill]

_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. 

[Pete]

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!

[OldMoses]

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...