How big is memory block after _MEMFREE?

[Petr]

Hi. Is this output correct? I think, after _MEMFREE is expected output zero?

Code: QB64: [Select]

1. Dim As _MEM l, r
2. l = _MemNew(50000000)
3. r = _MemNew(50000000)
4. Print l.SIZE, r.SIZE
5. _Delay .5
6. _MemFree l
7. _MemFree r
8. _Delay .5
9. Print "Size after MEMFREE:"; l.SIZE, r.SIZE
10. l = _MemNew(10000)
11. r = _MemNew(10000)
12. Print l.SIZE, r.SIZE
13.  

[OldMoses]

I guess the memory is freed, but the variable pointer still contains data until it is reassigned.

Code: QB64: [Select]

1. DIM AS _MEM l, r
2. l = _MEMNEW(50000000)
3. r = _MEMNEW(50000000)
4. PRINT l.SIZE, r.SIZE
5. _DELAY .5
6. _MEMFREE l
7. _MEMFREE r
8. CLEAR
9. _DELAY .5
10. PRINT "Size after MEMFREE:"; l.SIZE, r.SIZE
11. l = _MEMNEW(10000)
12. r = _MEMNEW(10000)
13. PRINT l.SIZE, r.SIZE
14.  

[Petr]

I guess the memory is freed, but the variable pointer still contains data until it is reassigned

Maybe, but is this so correct? I can't imagine using CLEAR other than at the end of the program before the SYSTEM statement.
I look to IDE Help and find _MEMEXISTS, so _MEMEXIST replaces this feature (if write to program something  as IF L.SIZE THEN... or if is used IF _MEMEXISTS(L)THEN... so it doesn't really matter. I just have to remember that the first method is not reliable.

[FellippeHeitor]

Like OldMoses said it, the memory is freed, but the variable isn't cleared. The same happens with _LOADIMAGE and _SNDOPEN, for example. They all return a handle, but calling _FREEIMAGE or _SNDCLOSE won't zero the handle variable, although the memory used by the resources does indeed get freed.

[Petr]

Like OldMoses said it, the memory is freed, but the variable isn't cleared. The same happens with _LOADIMAGE and _SNDOPEN, for example. They all return a handle, but calling _FREEIMAGE or _SNDCLOSE won't zero the handle variable, although the memory used by the resources does indeed get freed.

@FellippeHeitor
Thanks for confirming information by @OldMoses  I will remember it. I hope so. :)

[OldMoses]

I can't imagine using CLEAR other than at the end of the program before the SYSTEM statement.

Neither can I, in fact, this is about the only time I've ever used it. Given that those are the only two variables in the code, and CLEAR doesn't effect the previous static DIMing of them, I considered it the easiest way to null them.

[Pete]

@Petr "How big is memory block after _MEMFREE?" - I forget.

Kidding aside, like the other post confirmed, and QBasic was the same, which had the nice feature of the FRE() statement to check on memory usage.

@OldMoses I used to use CLEAR in QB. It worked great as a way to avoid using RUN to rerun a program. It was also a great way to zero all your variables, without creating a variable clearing routine. That was a perfect keyword for a run and gun programmer like me. I never kept track of my variable usage, and used hundreds of them for my largest apps. As for now? Now I avoid CLEAR; because unless it got a makeover in V2.0 (sorry, I haven't read the change log info yet), CLEAR in QB64 always failed to act properly. The same is (was?) true for the QB64 RUN statement. I'd like to mention what all those problems are (were?). One I believe was not resetting VIEW PRINT, and I think there were one or two others. It's just at my age, I tend to forget or conflate things. Not as bad as Joe Biden, and his orange complexion and gold colored hair, but then I didn't start out dumb as a stump and crooked as the tree that used to be there.

Pete :D