About the arrays

[636C65616E]

hmmm,

what i see now is a bit weird

changing the value in the array must not change his address, and futhermore as the references in $a and $b (the array address) have not changed, they should remain equal

like the abc of pointers, i can't see why they would not implement it this way ... 

Edited January 21, 2021 by 636C65616E

[JockoDundee]

6 hours ago, Nine said:

Nope.  Should be false as new memory address is assign to the array.

So to be clear, you agree that $a and $b have the same memory location right after:

Local $a = $b

but have different memory locations right after:

$b[0]=1

?

[Nine]

@JockoDundee  Yes.  See my previous post.

[Nine]

1 hour ago, 636C65616E said:

what i see now is a bit weird

I think it would be even more weird if after setting $a[0] = 9 to be still equals to $b.   That wouldn't make any sense...

[636C65616E]

there's a difference between $a[0] and $a

one is a scalar, the other is a ptr (or something similar for the VM)

ofc AutoIt doesn't handle array as C type stuff, but it needs memory addressing in the end, so this kind of scheme must exists

Edited January 21, 2021 by 636C65616E

[jchd]

Isn't this called copy on write?

[JockoDundee]

1 hour ago, Nine said:

@JockoDundee  Yes.  See my previous post.

I have, I was just looking to clarify.

What I don't agree with is this:

Quote

A patch has been sent by the devs for approval.  If accepted, comparing $b = $a will return True because memory address would be the same.

The danger is that such a change would be script breaking, since, rightly or wrongly, there is no doubt code out there that depends on the current behavior that would no longer work.

[Nine]

2 hours ago, JockoDundee said:

The danger is that such a change would be script breaking, since, rightly or wrongly, there is no doubt code out there that depends on the current behavior that would no longer work.

What are you talking about ?  Comparing arrays (with = op) was always returning the same result (False) whatever the arrays was, whatever you were comparing.  Unless you were using == which everything was True.  How a more intelligent comparaison would  be script breaking ?

Nobody was using intentionally :

Local $a[] = [1,2,3]
Local $b = $a
While Not ($b = $a)
WEnd

Instead of :

While True
WEnd

If someone was doing it, well I suppose it is time to change their scripts because it was not making much sense...

[JockoDundee]

56 minutes ago, Nine said:

Nobody was using intentionally :

Local $a[] = [1,2,3]
Local $b = $a
While Not ($b = $a)
WEnd

True, especially when a more economical option was available:

Local $a=[0]

Do

Until $a = $a

 

Edited January 22, 2021 by JockoDundee

[markyrocks]

I whipped together this example of a custom data type in autoit.  It offers the ability to compare 2 custom arrays bc its just a pointer comparison.  it does offer the ability to create an alias of another.  It is probably correct that this wont offer much in terms of performance gains, simply due to the fact that to dereference any pointer a struct has to be created which is just bananas(that includes any read or write operation).  I'm honestly considering something like this but using a helper c++ program that would allow me to dereference without jumping though all these hoops.  That and any memory operation is going to be 10x faster in c++ compared to autoit anyways so offloading all the heavy lifting would have serious speed benefits. 

asdfwefa.au3

Edited January 24, 2021 by markyrocks