I have read Thoughts for v2.0, Binary Data section, but not many details are given, and I have several doubts.
Currently this works as it should:
Code: Select all
str := f()
MsgBox str ; Hello ; OK
NumPut(32, &str+10, "UChar") ; 32 = SPACE
MsgBox str ; Hello world! ; OK
f()
{
str := "Hello world!"
NumPut(0, &str+10, "UChar")
MsgBox str ; Hello ; OK
return str
}
Code: Select all
Buffer := f()
MsgBox NumGet(&Buffer+10, "UChar") ; 0 ; WRONG
f()
{
local Buffer := ""
VarSetCapacity(Buffer, 100, 0)
NumPut(255, &Buffer+10, "UChar")
MsgBox NumGet(&Buffer+10, "UChar") ; 255 ; OK
return Buffer
}
lexikos: I would like to know what you have in mind and how this would affect the Scripts currently. It would be interesting to keep in mind when writing scripts for v2. If you are still not sure, we can discuss it right here.
I emphasize the use of binary data because I think it would be one of the most significant things that it will affect the majority of scripts currently written for v2. I think we should give high priority to this before anything else.
If VarSetLength is implemented, VarSetCapacity will accept the length of the string in characters, instead of bytes as it does now:
- VarSetCapacity will be used only to improve performance when using strings (optimise gradual concatenation). My question: Can it also be used in DllCalls when a string is to be stored?.
- If VarSetCapacity is going to be used only with strings, does it make sense to keep the FillByte parameter?.
- Should we add a parameter to VarSetCapacity to specify the encoding? (VarSetCapacity(TargetVar, Characters, Encoding:="UTF-16")).
- The memory is not completely released. We do not have an efficient memory management.
If we are going to reserve memory for a structure, obviously we want to have the exact amount of memory that we specify, and not "at least". What is wrong with reserving a few more bytes ?, Simple, we can not use VarSetCapacity as a sizeof, and some structures require that in its first member we specify its size, this must be exact, so we are forced to store the size in a separate variable (for example). Also, why reserve more memory if we are not going to use it?.https://lexikos.github.io/v2/docs/commands/VarSetCapacity.htm wrote:this function is often called simply to ensure the variable has a certain minimum capacity
I would like to propose, instead of VarSetLength, a Heap Object. The name of the function would be HeapCreate, for consistency with GuiCreate and MenuCreate.
The Heap object would look something like this: https://github.com/flipeador/AutoHotkey ... m/Heap.ahk.
Reasons:
- Greater handling and ease when recovering the reserved memory size, changing the size, etc.
- We can pass the object to a function (or return it) without having to copy the binary data.
- We can incorporate several methods to copy from/to without having several functions. This is normal when working with binary data, for example files or structures.
- [new] We could also have the ReadNum and WriteNum methods as FileObject. NumGet(&struct+Offset, "Int64")/NumPut(0, &struct+Offset, "Int64") => HeapObj.ReadInt64(Offset)/HeapObj.WriteInt64(Offset).
Code: Select all
Heap := HeapCreate()
Heap.Alloc(1024) ; set capacity
Heap := "" ; release it
Obj := { Buffer: HeapCreate().Alloc(1024) }
MsgBox Obj.Buffer.Length ; (or .size) 1024
In addition to all this, it would be interesting to remove ObjGetAddress, and be able to use &Obj.String and VarSetCapacity(Obj.String, 1024).