ArraySize() reports upper bound, not size, of Array

[Blue]

Code: Select all

Dim MyArray.l(1)                ; We have 2 elements
Debug "ArraySize(myArray()) = " + ArraySize(myArray())  ; reports 1, which is the upper bound, not the size

Dim anotherArray.l(0)           ; We have 1 element, therefore size of the array is 1
Debug "ArraySize(anotherArray()) = " + ArraySize(anotherArray())    ; the function reports 0 ! should be 1

More a misnomer, an error in logic, than a bug, really.
Still, for the sake of clarity, this function should be renamed ArrayLimit() or ArrayLast() or ArrayBound() or anything but ArraySize().

[NicTheQuick]

This change would break a lot of old code.
But anyway, you're right in my opinion.

+1

[mk-soft]

This change would break a lot of old code.
But anyway, you're right in my opinion.

+1

True. But it's not a bug.

[AZJIO]

Size can be interpreted in different ways, for example, a size indicator. The problem is that if you get the real size, then in the loop you will always have to specify ArraySize() - 1
Same friendly names ListSize and MapSize. It would be strange for an array to look for another function name.

[Blue]

Thanks, NicTheQuick, for getting the point.
Of course, a change to such a basic function would break a lot of code.

Specifically however, as mk-soft reminded us, it’s not a software bug. As I pointed out in my original post, it’s simply a poorly named function. Thus, a logical bug.

As for the notion that size can be interpreted in many different ways, that’s just convenient whitewash. ListSize() correctly reports the size of a list, MapSize() does the same for mapped data, but ArraySize() does something different than its name promises. So, in a business that thrives on rules and syntax and logics, I find it strange and distracting.

[skywalk]

I agree it is painful for my brain to remember such contradictions.
But Macro()'s can soften the blow if you must.

It is still less onerous than [CR+LF] vs [LF] or why we still have [in] vs [cm] in 2023

[Blue]

[…]
But Macro()'s can soften the blow if you must.

excellent … yes, macros are wonderful and super useful, especially the resident variety; with them, we can rewrite — or simply enhance — the whole language. But they can make debugging hellish…

[STARGÅTE]

If there will be the day when this is changed, I would also change the size specification in Dim and ReDim, to be consistent.
Then, Dim Integers(10), will create an array from index 0 to 9 (similar to static arrays).
Further, then we can use Dim Integers(0) to create an array with zero elements, which is not possible at the moment.
Currently, you need a separat variable to differentiate between a non-initialized array with ArraySize() = -1, an empty array with ArraySize() = 0 and an array of one element with ArraySize() = 0

[Blue]

Currently, you need a separat variable to differentiate between a non-initialized array with ArraySize() = -1, an empty array with ArraySize() = 0 and an array of one element with ArraySize() = 0

Ahhh… STARGÅTE. Still daydreaming, are you ? To be young and idealist, those were the days, weren’t they ?

[AZJIO]

Imagine that in order to return the correct size to you, you need to add one, and when you receive it, you subtract one. You have made a useless action.
I was once surprised that the array index starts from zero. But this is an existing thing, it cannot be zero. But then I got used to it, since many of the indexes of the ListIconGadget() item and other functions also start from 0. So if you start from 1, you would have to constantly subtract one to enumerate the elements. The character/cursor position in the editor can be zero-based, which is not logical. Having received the position, we need to take into account where the countdown starts, from 1 or from 0.
Why Arr(0) but "Procedure FuncName(Array Arr(1))"

[Blue]

Imagine that …

Are you trying to convince someone of something here ? I’m not sure I follow what your explanations, nor am I sure you’re getting the point.
Just the same, though, thanks for the input.

[Demivec]

Imagine that …

Are you trying to convince someone of something here ? I’m not sure I follow what your explanations, nor am I sure you’re getting the point.
Just the same, though, thanks for the input.

I think that ArraySize() is named correctly. It returns the dimensioned size, not the number of elements. I don't think it should be changed. I was bitten by this feature recently when i was converting code from another language whose size function counted the number of elements instead of returning the dimensioned size.

The missing ability to determine whether an array is null | empty mentioned by STARGÅTE is a byproduct of PureBasic's foundation. That is to say, it had been there from the start and I would guess it is not an easy thing to change. Even so, I agree with the thought that it would be helpful to have that functionality at times but I think it is more or less set in stone at this point.

[Blue]

… it is more or less set in stone at this point.

Agreed. And we’re all used to it. The experience you relate attests to that. Still, the fact remains, however, that better consistency would be desirable, and appreciated, in the logic department.

[AZJIO]

I’m not sure I follow what your explanations

Yes, Great, Right

Code: Select all

Define Dim Arr(5)
Define i

Arr(0) = 0
Arr(1) = 1
Arr(2) = 2
Arr(3) = 3
Arr(4) = 4
Arr(5) = 5

For i = 0 To ArraySize(Arr())
	Debug Arr(i)
Next

no, bad, wrong

Code: Select all

Macro ArraySize2(fuf)
	ArraySize(fuf) + 1
EndMacro

Define Dim Arr(5)
Define i

Arr(0) = 0
Arr(1) = 1
Arr(2) = 2
Arr(3) = 3
Arr(4) = 4
Arr(5) = 5

For i = 0 To ArraySize2(Arr()) - 1
	Debug Arr(i)
Next

How much of the essence is distorted by the double translation? (DeepL)
Is the essence strongly distorted after a double translation? (Google)

[Jeff8888]

I noted that the help file for arraysize says Arraysize returns the array dimension and not the array size.