This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
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?
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.
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.
The very existence of flamethrowers proves that at some time, some where, some place, someone once said to themselves "I'd really like to set those people on fire over there, but I just can't get close enough".
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 ]
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
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.
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 ...
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.
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.
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.
Joined: Dec 22, 2004
Sorry Fred, I meant Pat ...
Joined: Dec 22, 2004
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 ...
[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 ]
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Joined: Dec 22, 2004
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?
Joined: Jan 17, 2006
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.