Array Bounds

[Cliff Nichols]

I know somewhere in the docs it shows something about 0 based arrays vs 1 based arrays (but can't find it at the moment), but what I do not find is the following

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

    DIM MyArray() AS LONG
    MSGBOX FUNCNAME$ + $CR + "Lbound = " + TRIM$(STR$(LBOUND(MyArray))) + $CR + "Ubound = " + TRIM$(STR$(UBOUND(MyArray)))

END FUNCTION

An array purposely not dimensioned yet comes back with it appearing as if it has been dimensioned???
Lbound = 0, but Ubound reports correctly with -1
Am I missing something or is this a bug?

[Richard Angell]

Ms

Help file which you really should read
LBOUND:
"LBOUND of an undimensioned array returns zero"
UBOUND:
"UBOUND of an undimensioned array returns -1, so that UBOUND(array) - LBOUND(array) + 1 yields zero (0) for such an array."

Use ARRAYATTR as in:

MSGBOX FORMAT$(ARRAYATTR(MyArray(), 0))

Get right to the point!

Read the help on ARRAYATTR and you will see it is really useful to get at certain items of information about an array

[Cliff Nichols]

ok, I found why the Lbound = 0 without me dimensioning a size

When a program is first executed, PowerBASIC sets each element of a numeric array to zero, and sets each element of regular string arrays to a null string (length zero). However, when an absolute array is Dimensioned (at a specific location in memory using the AT address syntax), PowerBASIC does not initialize the memory occupied by the array. Further, when an absolute array is erased, the memory is not released either.

I also found more information on arrays (Determining type/size and other information) that I started writing a wrapper for, but my 1st problem, is that I thought if my function declaration used Variant for the type, then I could pass a LONG into the function, or a STRING, or any other type but I am wrong.

Do I have to declare a function for each type? (maybe passing a pointer is better?) I am looking into it.

[Cliff Nichols]

Thanks Richard,
It appears I was posting the same time you replied
ARRAYATTR is exactly what I am writing a wrapper for (maybe a lil overkill but could be handy)

[Rodney Hicks]

That seems to be in sync with the help file on UBOUND which states:

UBOUND of an undimensioned array returns -1, so that UBOUND(array) - LBOUND(array) + 1 yields zero (0) for such an array.

(-1)-(0)+(1)=0
Thus a value of -1 for UBOUND(array) is telling you that the array has not been dimensioned. Since all variables and arrays are created with a value of $NULL or 0 the LBOUND(array) would be 0, the default value as in DIM array(255) which gives you a 256 element array.(0-255)

I see overlapping posts all coming to the same conclusion.

[Michael Mattias]

Thus a value of -1 for UBOUND(array) is telling you that the array has not been dimensioned

No, it tells you you should have used ARRAYATTR(array(), 0) FIRST to see if the array has been dimensioned, because it's perfectly valid to ...

REDIM  Z ( -100& to -1&)

[Michael Mattias]

FWIW, UBOUND and LBOUND of an undimensioned array will set ERR 9 if you are compiling with #DEBUG ERROR ON.

Then again, who bothers with such trivialites as actually USING the provided error-handling tools?

[Rodney Hicks]

If the UBOUND =-1 and the LBOUND=0 it is telling me that the array is undimensioned, which he told us in his first post. By virtue of the relationship between the two. I could have been more clear by stating since the UBOUND<LBOUND the array is undimensioned.

[Michael Mattias]

If the UBOUND =-1 and the LBOUND=0 it is telling me that the array is undimensioned, which he told us in his first post. By virtue of the relationship between the two. I could have been more clear by stating since the UBOUND<LBOUND the array is undimensioned.

That is incorrect. The return values from UBOUND and LBOUND are invalid or undefined when called against an un-dimensioned array.

If you don't know if an array has been dimensioned, use ARRAYATTR with an option code of zero. Or, test ERR after calling LBOUND/UBOUND to see if a valid value has been returned.

Yes, I agree, the help file is a tad weak on this.

MCM

[Richard Angell]

I think the point I first posted, and Michael lastly re-inforced was that using the ARRAYATTR gets to the heart of the matter without using 2 BOUNDs calls and then the compare; and the compare is a necessity if you look at my original post form the UBOUND help. Just looking at the UBOUND is not enough as Michael succintly illustrated.

Yes, PB gives you the flexibility to do it both ways, but calling one function is more direct without the overhead of the additional call. You are not in VB_landia anymore ...

[Michael Mattias]

>Yes, PB gives you the flexibility to do it both ways

No, it doesn't.

PB gives you one discreet function to determine if an array has been dimensioned - that function is ARRAYATTR.

PB gives you LBOUND and UBOUND to get the bounds of a dimensioned array.

Think about it: is there even such a thing as an LBOUND or UBOUND if the array does not exist? LBOUND and UBOUND are meaningless in such a case.

>You are not in VB_landia anymore
I am thinking this is meaningful here; apparently VB does not offer an "is this array dimensioned" function?


MCM

[Richard Angell]

No, Michael, 2 ways, as the help file documents and I quoted:

UBOUND:
"UBOUND of an undimensioned array returns -1, so that UBOUND(array) - LBOUND(array) + 1 yields zero (0) for such an array."

The second way being the long way 'round to get an answer to is it dimensioned, hence you can find out with the "formula" in the help file ... but why? ARRAYATTR as we both have noted is the tool with the direct route.

VB does not apparently have an ARRAYATTR command, at least I did not find such in my VB6 docs.

[Rodney Hicks]

From his code:

DIM MyArray() AS LONG

I really didn't know that I could use DIM without subscripts as he shows. Isn't the purpose of DIM to apply the subscripts?
However he stated that the values he was getting for UBOUND and LBOUND were -1 and 0 respectively and according to the documentation receiving those values would tell you that you have an undimensioned array.

UBOUND of an undimensioned array returns -1, so that UBOUND(array) - LBOUND(array) + 1 yields zero (0) for such an array.

I was not suggesting that he apply the use of LBOUND or UBOUND again, I was just telling him that those were the values that he should have got for an array that was not dimensioned and apparently it applies if it dimensioned without subscripts.

Not withstanding, all else is as it seems. ARRAYATTR does all the wonderful things it should.

You are not in VB_landia anymore ...

Not sure just who this applies to, but I never was a VBer.

[Rodney Hicks]

Now this is really bugging me.

'UBOUND(myarray()) should return an error?
'LBOUND(myarray()) should return an error?
'ARRAYATTR(myarray(),x) should return what its supposed to
LOCAL myarray() AS LONG
'UBOUND(myarray()) should return -1
'LBOUND(myarray()) should return 0
'ARRAYATTR(myarray(),x) should return what its supposed to
DIM myarray(j TO k) 'is different than the syntax supplied.
DIM myarray() AS LONG  'the supplied syntax-no error?

There may be some error generated with regard to undeclared arrays versus undimensioned arrays and when to use UBOUND, LBOUND, or ARRAYATTR, but I'm not looking for this distinction, nor do I look for errors(they find me).

I revise. He was getting the information he should have got with what he had and the information should have told him that the array was undimensioned even though he had used the DIM statement.

[Richard Angell]

Using DIM MyArray() AS LONG can be done in BASIC, PB or VB, but this is only one part of the process, because it only declares the array (in this form without specified dimensions) , it does not allocate (dimension) it. Commonly though we usually see this for the declaration of global arrays, with other presentations in the help and these forums, where arrays declared in procedures are also being dimensioned. VB shows the declaration form above in some of its array discussions.

The VB remark is for those who are coming from VB to PB. For them it will be be helpful to use the help file, especially where they can use the see also quick links to other topics, such as in this case ARRAYATTR and see where PB offers much more in even the LBOUND and UBOUND functions than VB does.

Expecting an error from a UBOUND or LBOUND call to an un-dimensioned array in PB results in what the help file, already noted, returns. However trying to access an element of an undimensioned array is another matter.

[Michael Mattias]

Whoa, I have to learn how to read more carefully. That IS in the (8.03) help file like that, with artificial return values for LBOUND and UBOUND of un-dimensioned arrays.

IMO (that's the one you may debate), the way I described it is the way it should work. Sounds like leftover code from before the ARRAYATTR function was introduced (7x?).

[Cliff Nichols]

REDIM Z ( -100& to -1&)

An array with negative number of elements??? Not once have I seen an array with negative positions. For that matter you could REDIM Z ( -100& to 100&)
Only one situation I can think of for that would be for positions on either side of zero

You are not in VB_landia anymore ...

Yep, and thats what I am trying to untrain my brain from thinking...In VB an undimensioned array would return -1 for the LBOUND.

Once I had things straightened out in my head, I started out to write a wrapper for ARRAYATTR so I could call each attribute as a function (for my own readability cause the docs sometimes confuse me a little when it comes to ATTR functions)

I quickly found out, that unless I know the type of the array, this idea is worthless unless I want to write 24 functions for each attribute (1 for each word, dword, string, etc......)

so given that, I will stick with ARRAYATTR(Arr(), AttrNum) and comment heavier on the meaning of the AttrNum for readability in future use. (or better yet, use my own equates so it is self documenting like)

%ARRAYDIMENSIONED = 0
ARRAYATTR(Arr(), %ARRAYDIMENSIONED)

Hmmmm....that makes me wonder?? If you can get the attributes of an array, can you get the attributes of a variable to see if it were declared as long, or as string???

[Rodney Hicks]

Richard
It seems we're all on the same page.

It may be that since I never declare an array with the DIM statement that it seems unusual.

[Michael Mattias]

quickly found out, that unless I know the type of the array, this idea is worthless unless I want to write 24 functions for each attribute (1 for each word, dword, string, etc......)

Really? Single Function to process any array type (CC3/Win7+) 12-17-03

But that's overkill. MACROs get arround the problem, too:

MACRO IsArrayDimensioned (Z) =   ISTRUE (ARRAYATTR(Z(),0)) 

   LOCAL X() AS anything 

   i = IsArrayDimensioned(X)

Use a MACRO FUNCTION if you need the return value in the 'expression' position.


MCM

[Richard Angell]

Comments ARE the best "memory jogging" tool, IF they are accurate and understandable. I'm sure most of us would plead the fifth on having done just so all the time.

As to the variable type, use type specifiers or pop into a variant and do a VARIANTVT on it [Disclaimer, I'd not select the VARIANTVT route, since I'd probably try real hard not forget what variable type I was dealing with. Comment where needed.]