Index Zero

This is a copy of my post in reply to this comment about Tony's hate of starting the use of C arrays at '1':
http://greenstripe.blogspot.com/2009/05/i-recently-read-design-document-which.html

I think you know this, but you are confusing counting the number of something (to find the number in the set) with enumerating each item, thereby giving each one a numerical reference. For enumeration, there is no particular reason why the first reference has to be '0' or '1' or any other number - or in fact a number at all ... think Javascript arrays where the index is a string - this associative array is like a c++ map.

I'm not convinced that losing the memory for element 0 is, in most systems, critical. Except perhaps where you have constructors / destructors - then you are running code on element zero.

However, I do think there is a deeper problem in C with using 1 as the first element 'because it's seen by the user therefore the conceptual gap between problem domain and solution domain is smaller'. The first that comes to mind is that (a) the user display is tied to this ascending number sequence. We don't, I believe, naturally think of things as numbers - or named as numbered. Therefore there is a lost of abstraction that really could do with being hidden. Objects (e.g. with a C++ class) could sort this. Secondly, or (b), in C, at least, where I've seen this, there tend to be -1 and +1 sprinkled randomly around the code (without the help of object oriented design). Thirdly, or (c), (what do you mean I've run out of enumerations?!) if you have to remove an element or make the list bigger in the middle, or do any sorting, then the index (which is what we are talking about) becomes invalid. But the user numbering, apparently, does not. Doesn't that mean that the whole 'fixed sequence' is an artificial construct of the specifier or developer? Where does this leave the user?

I'm sure there are more ...

One last thing: I can hear a bunch of programmers saying "but on small systems"/"my system" it's the most efficient way of showing something. But that's not the argument here. Either: (a) you bit the bullet and go for efficiency and ignore usability or (b) you abstract the user from the internals of the program but make the internal of the program easy to maintain. The third option making it easy by removing abstraction only works in very narrow cases and tends to be fragile to change.