Forums Register Login

Why 0 based arrays?

+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
you could always pretend like java started with 1... as long as you declare your arrays bigger than you really need them.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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 ...
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
 

Originally posted by Guido Sautter:
Hi Fred,

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


That wasn't me.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
Sorry Fred, I meant Pat ...
+Pie Number of slices to send: Send
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 ...
+Pie Number of slices to send: Send
[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 ]
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
No what I'm saying is the compiler could treat these two instances differently:



However I fear we're getting into the territory of hijacking this thread which was about a different topic entirely.
a fool thinks himself to be wise, but a wise man knows himself to be a fool - shakespeare. foolish tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 6603 times.
Similar Threads
rounding issue with BigDecimal
Small Query regarding EL
MatchResult.start() & MatchResult.end() methods
Why ResultSet's index Starts with '1' instead of zero?
I can't seem to get gredorian calender working right
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 07:56:56.