A_Index0 Topic is solved

Propose new features and changes
User avatar
jeeswg
Posts: 6715
Joined: 19 Dec 2016, 01:58
Location: UK

A_Index0

13 May 2019, 02:22

I was thinking that I might like to avoid using the Offset parameter in NumGet/NumPut. But having the Offset parameter available lets you avoid using parentheses, where parentheses obscure the code.

An A_Index0 variable (or another name), a 0-based index in a Loop, would make it more viable to stop using the Offset parameter.

Code: Select all

;1-based:
for vKey, vValue in [1, 2, 3, 4]
	NumPut(vValue, &RECT+(A_Index-1)*4, "Int")

;0-based:
for vKey, vValue in [1, 2, 3, 4]
	NumPut(vValue, &RECT+A_Index0*4, "Int")
Last edited by jeeswg on 13 May 2019, 10:24, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
just me
Posts: 6486
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: A_Index0

13 May 2019, 03:15

Code: Select all

#NoEnv
; 1-based:
VarSetCapacity(RECT, 16, 0)
Addr := &RECT
For Key, Value In [1, 2, 3, 4]
   Addr := NumPut(Value, Addr + 0, "Int")
MsgBox, % GetRect(RECT)
ExitApp

GetRect(ByRef RECT) {
   RetVal := ""
   Addr := &RECT - 4
   Loop, 4
      RetVal .= ", " . NumGet(Addr + A_Index * 4, "Int")
   Return SubStr(RetVal, 3)
}

BTW: How would the parentheses in ...+(A_Index-1)*... obscure the code?
User avatar
jeeswg
Posts: 6715
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_Index0

13 May 2019, 03:48

- Looking through various scripts, one of the main problems is having nested parentheses, within nested parentheses etc.
- When you have too many parentheses/commas/double quotes, and sometimes literal versions of those characters, it can be a problem to read. For literal characters, it can sometimes be good to have a variable e.g. A_Comma/A_DQ (proposed).

- You're using the return value of NumGet (cryptic/verbose), and an initial subtraction (less bad, but still relatively complex for a standard situation).
- Some other workarounds, that aren't great either:

Code: Select all

for vKey, vValue in [1, 2, 3, 4]
	vIndex := A_Index-1, NumPut(vValue, &RECT+vIndex*4, "Int")

for vKey, vValue in [1, 2, 3, 4]
	NumPut(vValue, &RECT+A_Index*4-4, "Int")

vIndex := -1
for vKey, vValue in [1, 2, 3, 4]
	vIndex++, NumPut(vValue, &RECT+vIndex*4, "Int")

- Sometimes, you could get some nice results by using A_Index and A_Index0 together.
Last edited by jeeswg on 13 May 2019, 10:25, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
guest3456
Posts: 2572
Joined: 09 Oct 2013, 10:31

Re: A_Index0

13 May 2019, 09:46

jeeswg wrote:
13 May 2019, 02:22
An A_Index0 variable (or another name)
well A_ZeroIndex would be better. but i have no opinion on whether this is needed or necessary

User avatar
jeeswg
Posts: 6715
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_Index0

13 May 2019, 10:02

Yeah, that's nice, I was thinking something like that, with a 'Z' somewhere, after the initial idea. I'm 50/50 on the overall idea, but thought it was worth posting, to see if I got any good feedback.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
guest3456
Posts: 2572
Joined: 09 Oct 2013, 10:31

Re: A_Index0

13 May 2019, 10:09

prob vote against. why isn't this the standard workaround

Code: Select all

;1-based:
for vKey, vValue in [1, 2, 3, 4]
{
	i := A_Index-1
	NumPut(&RECT+i*4, vValue, "Int")
}

User avatar
jeeswg
Posts: 6715
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_Index0

13 May 2019, 10:23

That probably is the least worst. I'll consider 'voting' against the idea for now, but maybe something interesting relating to it will come along at some point.

[EDIT:] I only had the idea today, after thinking about removing the Offset parameter. I've since considered that the trailing '0' could get mixed up with any nearby numbers.

[EDIT:] I was excited, not just by the idea itself, but that some subtle addition regarding A_ variables, in some long-standing basic functionality, could make a big difference re. coding.

Here's another idea:

Code: Select all

for vIndex, vValue in [11, 22, 33, 44]
	vIndex--, NumPut(vValue, &RECT+vIndex*4, "Int")
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
just me
Posts: 6486
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: A_Index0

13 May 2019, 10:52

jeeswg wrote:- You're using the return value of NumPut (cryptic/verbose) ...
That's one important reason why NumPut() returns that address. So why do you call it 'cryptic/verbose'?
User avatar
jeeswg
Posts: 6715
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_Index0

13 May 2019, 10:59

Some things are more intuitive than others. It still doesn't seem intuitive/memorable to me, that, and despite being useful, NumPut returns the address it receives plus the size of the type.

Also, I think that nested NumPuts look unclear, and obscure the code. So, I would restructure any such code, or possibly create an alternative function.

Also, people less familiar with AutoHotkey or programming might be more able to infer what was going on in some of the other examples, versus the NumPut return value example.

Btw, nested NumGets *are* often intuitive. Commonly used to retrieve a pointer, and then retrieve the value at that pointer. This is often used with interface methods.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
swagfag
Posts: 2912
Joined: 11 Jan 2017, 17:59

Re: A_Index0

13 May 2019, 13:12

guest3456 wrote:
13 May 2019, 10:09
why isn't this the standard workaround

Code: Select all

;1-based:
for vKey, vValue in [1, 2, 3, 4]
{
	i := A_Index-1
	NumPut(&RECT+i*4, vValue, "Int")
}
i thought it was. it certainly is the most "readable" one of the bunch
A_ZeroIndex looks fine, too. perhaps, a bit wordy

the rest dont seem very intuitive at all. forloops mutating the key once, then u mutate it a second time with post/prefix. this is of course crammed into 1 line
i say stick to (A_Index - 1) or i := A_Index - 1
lexikos
Posts: 6600
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: A_Index0  Topic is solved

14 May 2019, 21:52

No.
User avatar
jeeswg
Posts: 6715
Joined: 19 Dec 2016, 01:58
Location: UK

Re: A_Index0

15 May 2019, 10:09

Two other ideas. Zero-based index.
A_ZBIndex. Better, as less cognitive conflict with A_Index.
A_IndexZB.

I'm happy with 'No', although I didn't mark the thread solved.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
lexikos
Posts: 6600
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: A_Index0

16 May 2019, 22:11

Neither did I, FYI.
User avatar
Cuadrix
Posts: 204
Joined: 07 May 2017, 08:26

Re: A_Index0

18 May 2019, 00:33

I say just get used to the regular Autohotkey style index, or start using Python
----
Sam_
Posts: 106
Joined: 20 Mar 2014, 20:24

Re: A_Index0

29 May 2019, 09:21

I have several large scripts that work with binary data structures (which are all 0-indexed). I store them as arrays for ease of manipulation, and to simplify things the arrays are also 0-indexed. This means that the first line of every loop in the script (and there are many) is Index:=A_Index-1. It would simplify things considerably if something like A_ZeroIndex was implemented.

I doubt any of this will ever be implemented, but while we're on the subject I had a somewhat different idea for a solution. My idea was to have a special built-in variable (A_Origin) which is editable and can be used to set the origin/starting value of A_Index within all loops. Thus

Code: Select all

A_Origin:=0
Loop, 3
	MsgBox % A_Index ; Would be 0 on the first loop, 1 on the second, 2 on the third, etc.
Personally, I would also like A_Origin to set the origin/starting index of arrays:

Code: Select all

Arr:={}
Arr.Push(0)
For k,v in Arr
	MsgBox key %k% has value of %v% ; key 1 has value of 0


A_Origin:=0
Arr:={}
Arr.Push(0)
For k,v in Arr
	MsgBox key %k% has value of %v% ; key 0 has value of 0
The other approach I thought of would be to have a #Directive to set the origin to 0 instead of 1 (instead of the special variable). In hindsight, A_ZeroIndex is probably a better solution since it would prevent messing up imported/existing code not designed with the possibility of an Origin other than 1 in mind.
User avatar
nnnik
Posts: 4253
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: A_Index0

29 May 2019, 10:04

I disagree with both. It makes scripts largely incompatible with one another just with one setting.
Recommends AHK Studio

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 5 guests