If you use REDIM
- to 'delete' an integer array, array.count gets not updated, so FOREACH thinks the array is still big and calls the deleted entries too. LEN and BOUNDS work correct. The bug only happens with integer arrays and when you REDIM it to
- , all other values work fine, so do arrays of floats, string and types. I did only test V11.
Here is an example:
LOCAL a%[]
DIM a[4]
FOR i%=0 TO a.count-1
a[i]=i
NEXT
REDIM a[0]
DEBUG "count: "+(a.count)+" len: "+LEN(a[])+" bounds: "+BOUNDS(a[],0)+"\n"
DEBUG "elements with foreach:\n"
FOREACH b IN a[]
DEBUG b+"\n"
NEXT
DEBUG "elements with for:\n"
FOR i%=0 TO LEN(a[])-1
DEBUG a[i]+"\n"
NEXT
This is the output that i get from this example:
count: 4 len: 0 bounds: 0
elements with foreach:
0
1
2
3
elements with for:
BTW. did I win a prize for finding the most exotic bug in the new year? :D
Quite true - obviously that is an internal count...
Oh. If that's true its a good find. These things cause really trouble.
Interesting, didnt know there was a DOT count feature.
Is this intended to be quicker than LEN and BOUNDS?
Array.count is no official GLB feature/syntax, its a 'hack' that uses GLB intern C transformation. It is faster than LEN/BOUNDS, but I dont know if its save (and if it will be in the future), but I use it quite some time without problems (and since it is used in FOREACH intern, it should be no problem to use it). Obviously it just works with integers, floats and strings, but not with types (I have no idea, how to do this with types...). If you want to do it on a String array, LEN(array$[]) turns into array_Str.count.
Btw. I was always thinking about creating a thread where we could collect all the cool 'hacks' and workarounds, that make life easier...
I posted it here just cause I already tracked down the error to this counter, so Gernot just needs to do a shorter search on his own.
It's not a new bug. Doesn't work in 10.283 version either.