specifically
Code: Select all
NumGet(&this + 4*A_PtrSize)
Code: Select all
NumGet(&this + 4*A_PtrSize)
Code: Select all
0 vTbl pointer
2*8 8 mRefCount
mBase: address of base object, 0 if none
16 mFields: Array of pointers to the object's keys
4*8 32 mFieldCount: Current number of key-value pairs = Obj.Count()
5*8 40 mFieldCountMax: Current capacity of the object = Obj.GetCapacity()
6*8 48 mKeyOffsetObject: Index of the first possible object key in mFields
This is equal to the current number of integer keys
The current number of object keys is: mKeyOffsetString-mKeyOffsetObject
The current number of string keys is: mFieldCount - mKeyOffsetString
how? well, for a few years AHK missed a bullet-proof (reliable, convenient, performance-wise decent) way to count pairs key-value in the associative arrays and objects.
Code: Select all
o := {}
msgbox dllcall(numget(numget(&o)+a_ptrsize), 'ptr', &o, 'uint') ; addref
msgbox dllcall(numget(numget(&o)+a_ptrsize*2), 'ptr', &o, 'uint') ; release
thank u, Helgef! very interesting
No doubt. All that r bad practices. But a script can be "statically-linked" ("compiled" into .exe) with particular AHK version. And sometimes performance > compatibility.
One more thought. They r definitely NOT useless. For example, if one writes in C++ language and studies how C++ compiler turns his lines into resulting machine assembly code, he can find ways/styles of writing more effective C++ algorithms with increased performance and reduced resources consumption, w/o even programming in assembly directly.
Yes. I was in the middle of correcting my post above. Internally they r divided into 3 grps and searched separately. But integer keys r like 2-3 times as fast according to my synthetical tests
Also:
Doesn't it look like making a key _name_ as an object makes no sense. Just a quirk of syntax. key name _IS_ stored internally as an object type tho. Im lostThe key's value is preserved, but its type identity is not. That is, integers may be stored as strings or vice versa, so long as the value remains the same (including the formatting of numeric strings).
I do not know what you mean by key _name_.Doesn't it look like making a key _name_ as an object makes no sense.
So the key doesn't have a _name_, it has a _value_, (and is associated with another value)The key's value is preserved,
Code: Select all
for k, v in { func('msgbox') : 'hello world' }
%k%(v)
Do u believe quirks and irregularities compared to recognized standards would make AHK better? AHK can be whatever its current developers want it to be. But if AHK is to compete with top 50 languages at least, it has to be structured and clear as much as possible. It had the long haul coming from a script with set of commands (AutoIt v1) to an interpreting language (AHK v2), why should it stop in midway? Lexikos is genius, the community is great here. The issue lies in trying to stick to esoteric heterogeneous features by the cost of language clarity. My humble opinion.How does that relate to my comment?
"string name" or integer index it can be referenced to. e.g. JSON format has only 1 type for a key's name: string (array elements has no names).I do not know what you mean by key _name_.
Users browsing this forum: No registered users and 131 guests