A VERY smart way to allocate memory

[Mike Trader]

Yes, I agree. It seems like the PB compiler is working perfectly.
If they do break it in future, it would not be too hard to switch over to the very fast Heap Functions because the initial size of the string is essentially the initial size of the Heap.

http://msdn2.microsoft.com/en-us/library/aa366711.aspx

[Michael Mattias]

You really need to get a statement from PowerBASIC on this. Contact support.

It still comes down to the implementation/treatment of this:

I would think if a LOCAL UDT contains a STRING PTR member, that string would be freed when the procedure exits and the LOCAL UDT goes out of scope. (Just like a LOCAL STRING PTR variable would be freed)

I still think that. But it's not my call to make.

After further review, I don't think that anymore. The rest of your comments have convinced me othewise.

In your example of assigning the return of VirtualAlloc directly to a PB PTR variable type, now I know why the scope protection of UDT members is provided... to prevent the compiler from automatically attempting a deallocation when it has no clue how the allocation was made. i.e VirtualFree against something allocated with SysAllocStringByteLen could be at a minimum, well, "exciting."

[Mike Trader]

I am uncertain if this "trick" is now considered valid:

http://www.powerbasic.com/support/forums/Forum4/HTML/012511.html

Based on Lothar's work:

http://www.powerbasic.com/support/forums/Forum7/HTML/002837.html

and

http://www.powerbasic.com/support/forums/Forum7/HTML/002364.html

'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
FUNCTION GetMem( BYVAL memSize AS LONG ) AS LONG ' a very smart way to allocate memory ... 

  LOCAL MemHandle AS LONG
  LOCAL MemString AS STRING PTR

    MemString  = VARPTR(MemHandle) ' String Pointer points to a NULL pointer to the data (allowed for OLE strings)
    @MemString = STRING$(MemSize, CHR$(0)) ' Allocate Memory ... MemHandle now points to the Memory data

  FUNCTION = MemHandle ' MemHandle = handle to Memory, pointer to the data  

END FUNCTION
     
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
SUB ReleaseMem( BYVAL MemHandle AS LONG ) 

  LOCAL MemString AS STRING PTR
    
    MemString  = VARPTR(MemHandle) ' let MemString be a pointer to the string which handle is MemHandle
    @MemString = "" ' release the Memory ... -> MemHandle = 0

END SUB

I have been using this for a couple of years with success, but I am considering adapting a linked list to run within memory assigned in chunks
this way.

It's been good for a couple of years and a version (or two?) of PB but I am wondering if future versions of the PB compiler might break it because it is a "trick"?

notwithstanding

http://www.powerbasic.com/support/forums/Forum4/HTML/011541.html

and

http://www.powerbasic.com/support/forums/Forum4/HTML/010707.html

http://www.powerbasic.com/support/forums/Forum4/HTML/010338.html

http://www.powerbasic.com/support/forums/Forum7/HTML/001560.html

When used like inthe String builder example StringBuilder_New(), Lothar uses

psb = VirtualAlloc(BYVAL %NULL, SIZEOF(@psb), %MEM_RESERVE OR %MEM_COMMIT, %PAGE_READWRITE)

To allocate the UDT memory. I assume this means the scope of the STRING is beyond PB recource management and remains available globally until deallocated or the process terminates?