Element 0 in arrays

[PhilOfPerth]

Should it be (or is it already) mentioned in the Wiki,  that Dim var(num of elements) allows element 0, as well as the number of elements dimmed ?
So Dim var(10) actually allocates 11 element positions, not 10. (Or does it)?

This may become significant for memory usage with multi-dimensional arrays:
Dim var(10, 1000) would occupy space for about 11 * 1001 units (11011), not 10000 as I would expect.

[RhoSigma]

Should it be (or is it already) mentioned in the Wiki,  that Dim var(num of elements) allows element 0, as well as the number of elements dimmed ?
So Dim var(10) actually allocates 11 element positions, not 10. (Or does it)?

This may become significant for memory usage with multi-dimensional arrays:
Dim var(10, 1000) would occupy space for about 11 * 1001 units (11011), not 10000 as I would expect.

It's mentioned already in the first two lines in the Wiki description:
https://qb64phoenix.com/qb64wiki/index.p...escription

Zero is the default for lowest index, to override use OPTION BASE 1 before DIMing your arrays or hard index your arrays using the DIM xxx(lb TO ub) syntax (see Wiki Example 4).

[SMcNeill]

If you don't want arrays to start at 0, use:

OPTION BASE 1

[PhilOfPerth]

Should it be (or is it already) mentioned in the Wiki,  that Dim var(num of elements) allows element 0, as well as the number of elements dimmed ?
So Dim var(10) actually allocates 11 element positions, not 10. (Or does it)?

This may become significant for memory usage with multi-dimensional arrays:
Dim var(10, 1000) would occupy space for about 11 * 1001 units (11011), not 10000 as I would expect.

It's mentioned already in the first two lines in the Wiki description:
https://qb64phoenix.com/qb64wiki/index.p...escription

Zero is the default for lowest index, to override use OPTION BASE 1 before DIMing your arrays or hard index your arrays using the DIM xxx(lb TO ub) syntax (see Wiki Example 4).

Sorry, missed it!   
Thanks for the reply

[RhoSigma]

This may become significant for memory usage with multi-dimensional arrays:
Dim var(10, 1000) would occupy space for about 11 * 1001 units (11011), not 10000 as I would expect.

To be honest, I'd say this is negligible for todays memory setups:

eg. DIM var(1000, 1000, 1000) AS DOUBLE

You'd expect 1'000'000'000 elements, but for real its 1'003'003'001 elements, hence you've 3'003'001 elements more each 8 bytes (DOUBLE), so its approx. 24MB more.
For SINGLE or LONG (4 bytes each) arrays it would only be 12MB and for INTEGER (2 bytes) it would be 6MB more space.

Even on my old Laptop with ONLY 4GB RAM I wouldn't care about the additional 6-24MB, but for real I trained myself already years ago to DIM one index less than I need and always start my counting at index zero , that habit it's much easier because other languages like C/C++ don't have the ability of an OPTION BASE 1, but always start at element zero.

[a740g]

This can become problematic if you pass the address of the arrays to C functions IMO.

A safer and better way to declare arrays is by always using the `TO` keyword.

Like `DIM myArray(1 TO 1024) AS DOUBLE`.

That way the arrays aways have the exact number of elements regardless of the `OPTION BASE` setting.

[RhoSigma]

This can become problematic if you pass the address of the arrays to C functions IMO.

A safer and better way to declare arrays is by always using the `TO` keyword.

Like `DIM myArray(1 TO 1024) AS DOUBLE`.

That way the arrays aways have the exact number of elements regardless of the `OPTION BASE` setting.

That's definitly true, especially if you make a library where you never know if the people using your library have OPTION BASE 1 in effect or not.

However, my point was that as a programmer its generally better to start counting at zero rather than one, cause that't the natural way in most programming languages where eg. array indices are nothing else than memory offsets.

[mnrvovrfc]

This can become problematic if you pass the address of the arrays to C functions IMO.

A safer and better way to declare arrays is by always using the `TO` keyword.

Like `DIM myArray(1 TO 1024) AS DOUBLE`.

That way the arrays aways have the exact number of elements regardless of the `OPTION BASE` setting.

I couldn't agree more with this.

One of the most irritating error messages I got from BASICA or from QuickBASIC had to do with arrays. I almost never cared about the zeroth subscript of an array. To the point where I became a bit puffed up at the incredible manipulations in Turbo Pascal libraries which showed source code; instead of using `Length()` function on a "shortstring", used the zeroth subscript to retrieve the fake string length or to set it. I'm glad now Free Pascal returns an error if an attempt is made to fuss with the zeroth element of any string. (It supports the "shortstrings" which were the ones originally supported by Turbo Pascal which couldn't be longer than 255 characters, and the "longstrings" which are like VLS in BASIC. There is also a difference there between "ansistrings" which are 8-bit and Unicode strings.)

Sorry for going off topic and into another programming language, but I'm attempting to explain that the zeroth array element wasn't a big deal for me. I always started at 1 and expected it. Whichever programming language must have the first element as "number 0" obviously has to interface with C/C++ as much as possible. The authors of Freebasic and Free Pascal made that choice with "open" arrays, in which the number of elements is not known in declaration.

I forced myself to use `DIM` to declare arrays because in QB64 v0.98 and older I started running into problems with a few functions I wrote accepting four or more parameters. It kept confounding a function I wrote for an array and that's why it crashed into "Out of Memory" runtime message box. I had to make sure to include the code body for that function as well as declare any array that was used. I like using "TO" because it's more legible to someone else and I'm not very good with commenting my code. I'm pretty much the opposite of Terry.

[PhilOfPerth]

This can become problematic if you pass the address of the arrays to C functions IMO.

A safer and better way to declare arrays is by always using the `TO` keyword.

Like `DIM myArray(1 TO 1024) AS DOUBLE`.

That way the arrays aways have the exact number of elements regardless of the `OPTION BASE` setting.

I couldn't agree more with this.

One of the most irritating error messages I got from BASICA or from QuickBASIC had to do with arrays. I almost never cared about the zeroth subscript of an array. To the point where I became a bit puffed up at the incredible manipulations in Turbo Pascal libraries which showed source code; instead of using `Length()` function on a "shortstring", used the zeroth subscript to retrieve the fake string length or to set it. I'm glad now Free Pascal returns an error if an attempt is made to fuss with the zeroth element of any string. (It supports the "shortstrings" which were the ones originally supported by Turbo Pascal which couldn't be longer than 255 characters, and the "longstrings" which are like VLS in BASIC. There is also a difference there between "ansistrings" which are 8-bit and Unicode strings.)

Sorry for going off topic and into another programming language, but I'm attempting to explain that the zeroth array element wasn't a big deal for me. I always started at 1 and expected it. Whichever programming language must have the first element as "number 0" obviously has to interface with C/C++ as much as possible. The authors of Freebasic and Free Pascal made that choice with "open" arrays, in which the number of elements is not known in declaration.

I forced myself to use `DIM` to declare arrays because in QB64 v0.98 and older I started running into problems with a few functions I wrote accepting four or more parameters. It kept confounding a function I wrote for an array and that's why it crashed into "Out of Memory" runtime message box. I had to make sure to include the code body for that function as well as declare any array that was used. I like using "TO" because it's more legible to someone else and I'm not very good with commenting my code. I'm pretty much the opposite of Terry.

 All very enlightening. I think I like the TO approach, at least for general usage, but at present I  want to use the zero'th element to hold other information (colour for example), so I'll use the zero-based version, with an extra element. Thanks for all the good info.