Why 0 based arrays?

[Norm Radder]

Looking for some history.

I'm sure there have been 10s of thousands of hours spent by programers trying to find programming problems cased by 0 based array indexing. Its easy to think the index for first one must be 1, etc.
Why did the Java designers use 0 based indexing?
Must be legacy from C. Poor excuse to continue to use a scheme that is prone to error.
Is there any other possible reason?

[Joe Ess]

Zero-based arrays make sense to me. Until you've traversed the first element, you've accumulated zero elements. Like running a mile. Until you've passed that first mile marker you've got zip.
The concept has a more solid foundation in C because the memory address of an array is also the address of the first element in the array. The address is literally "array plus zero". Not having pointers in Java makes it seem kind of arbitrary.

[Nathan Leniz]

I don't see how it's poor at all. Array indexes are just that. If I have 20 elements in an array, the one in 19th position (the last one) is 19 places away from the1st element, which is zero away from the beginning. Makes complete sense to me.

Here's an article on why we should start from 0.
And here is a link to an older JavaRanch subject.

[fred rosenberger]

once you figure it out, it's trivial. However, a lot of people go back and forth between the two languages. think of how many MORE hours would be lost by developers who are constantly switching.

One of the big benefits, and design decisions, of java was to make the transition as easy as possible. changing the array indexing would NOT have been easy or popular.
[ July 22, 2008: Message edited by: fred rosenberger ]

[Ernest Friedman-Hill]

I like the well-known quote from columnist Stan Kelly-Bootle: Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. The moral is, I think, that whatever you think is best, seems best to you. One could make convincing arguments either way.

[Rob Spoor]

Well, Pascal and Delphi have a good solution too, I think. They allow you to specify both upper and lower bounds of the array, e.g.

array[-128..127] of integer

[Paul Clapham]

And if I recall correctly, Visual Basic allowed your arrays to start at either 0 or 1, depending on what default you stated at the beginning of your code.

[fred rosenberger]

you could always pretend like java started with 1... as long as you declare your arrays bigger than you really need them.

[Pat Farrell]

Java does it because C did it. Java had to appeal to the C programmers, which is why we are cursed with int, float, etc. rather than Integer and Float.

Why did C do it? Because C is just PDP-11 assembly language with some minor syntactic sugar. Assembly languages always use zero based.

Fortran for ages used ones-based indexing, but about 1977, they decided that was a silly restriction, so they let you specify lower and upper bounds.

for 99% of the time, I'm happy with zero based. I do always struggle with date formats, where January != 1

[Guido Sautter]

Hi Fred,

what do you mean "we're cursed with int, float, etc."? Using the respective objects is necessary when using them, say, as keys in a Map, but in numerical computations, where performance really counts, having the plain primitive types is a blessing, not a curse ... Imagine how much processing time would be wasted creating and garbage collecting (immutable) objects if we didn't have the primitive types. Imagine what a for-loop would look like.

Plus, after all, there has to be some sort of literals in any programming language. And I think Java is doing quite fine with the choice of primitive types it offers. Though I miss unsigned numbers from time to time ...

[Jeanne Boyarsky]

Originally posted by fred rosenberger:
you could always pretend like java started with 1... as long as you declare your arrays bigger than you really need them.

Of course, this isn't such a good idea when you work on a team since your teammates will be using the standard convention of starting with zero. They would spend hours hunting down bugs caused by the 0'th element being null. And you would spend hours in their code forgetting the array starts at 0.

My point is that whatever makes most sense to you, it's good to develop the habit of starting with zero so you get used to it.

[David O'Meara]

Originally posted by Pat Farrell:
Why did C do it? Because C is just PDP-11 assembly language with some minor syntactic sugar. Assembly languages always use zero based.

To me this approaches 'the answer'.
Assembly uses address locations and not arrays, but arrays are (were) defined as a base memory location (b) and memory allocation (a) for each item. The memory location for each item was therefore b + i x a when using a base of zero, but b + (i - 1) x a when using arrays based on 1.

While immediately this is not a large change, it is when you constantly have to repeat it in assembly code, and has immediate performance benefits if your code does this sort of thing all day, every day.

IMO. Have no references for this

[fred rosenberger]

Originally posted by Guido Sautter:
Hi Fred,

what do you mean "we're cursed with int, float, etc."?

That wasn't me.

[fred rosenberger]

Originally posted by Jeanne Boyarsky:

Of course, this isn't such a good idea when you work on a team since your teammates will be using the standard convention of starting with zero.

I didn't say it was a GOOD idea, or that I recommended it. Just that you could do it.

[Guido Sautter]

Sorry Fred, I meant Pat ...

[Guido Sautter]

And, by the way, it's of great use to start thinking a little in C/C++ for understanding how Java (and its JVM in particular) works internally. That's something not to forget about when thinking about execution performance, since C/C++ is way closer to how hardware actually works, and probably will work for for the near future. And every JVM implementation has to finally interact with actual hardware ...

[Garrett Rowe]

[Guido Sautter]: Using the respective objects is necessary when using them, say, as keys in a Map, but in numerical computations, where performance really counts, having the plain primitive types is a blessing, not a curse ... Imagine how much processing time would be wasted creating and garbage collecting (immutable) objects if we didn't have the primitive types.

This is something the compiler or the runtime could optimize away. If the compiler can infer that only primitive operations are being done, then it can map directly to come underlying primitive type, otherwise, it could promote them to some boxed type, transparently. Opaquely exposing raw primitives in a language isn't necessary for the language to be *fast* or *efficient*.

All of this is just hypothetical though. Java has primitives and zero based arrays and always will. When programming in Java, you use the constructs that the language provides. Just my .02
[ July 22, 2008: Message edited by: Garrett Rowe ]

[Guido Sautter]

But that would mean the compiler would have to treat the 'new' keyword differently for different classes, which is, imho, pretty undesirable.

Plus, it would either render the syntax in basic mathematical operations very unintuitive (Integer result = i1.add(i2), with i1 and i2 some Interger objects), or induce a lot more special treatment of operators beside the treatment of '+' in combination with String objects. The latter would add a lot of complexity to the compiler, and the former would (probably) reduce acceptance of Java as a programming language ...

Finaly, every programming language needs some sort of literal. What would that be, if not primitive types?

[Garrett Rowe]

No what I'm saying is the compiler could treat these two instances differently:

int x = 4;
 
int y = x + x;  //Behind the scenes use a primitive int
String z = x.toHexString(); //Promote x to a wrapper type transparently

However I fear we're getting into the territory of hijacking this thread which was about a different topic entirely.