Why the base index of array is zero in c language?
 

I was trying to work with array in c language and wondered that the base index of array does not start with other than zero like it doesn’t start with 1, 2, 3.. I just want to know the concept behind.
“Why the base index of array is zero in c language” As I am a beginner in c programming language and I have more doubts about C issues, I will definitely post and look for more c programming questions and answers in this community forum. Hope I will get genuine replies to my programming query.

I don't know for certain but I would think it could be that counters always start at 0 not 1. That goes for anything from stopwatches to ripple counters meaning that in computing counting starts at 0. Since computing starts counting at 0 so does C.
Of course, it could just as easily be for aesthetic reasons.

One design feature of C makes arrays and pointers look as much as possible like the same thing, so x[n] and *(x+n) mean the same thing, regardless of whether x is an array or a pointer. Obviously, you want *x and *(x+0) to mean the same, which would be very confusing is the first element of arrays were not index 0.

Think like a CPU chip. When you are using "indexed addressing," an offset taken from an appropriate hardware register is added to the address. This is exactly what "C" is doing when referencing an array or taking an offset from a pointer. (The latter being "indexed indirect addressing.") The minimum offset is zero.

"C" is a very low-level language designed to be "one step above assembler," and in fact to incorporate an assembler in the form of the asm{...} block. All of the constructs in "C" correspond more-or-less directly to hardware concepts and to machine instructions. This is by design.

Hi!

I haven't ever stumbled upon a language that do NOT start at zero when handling arrays. In other words, it's not a "C" thing.

Best regards,
HMW

I seem to recall that something like Visual Basic had an option to start arrays at 1 but my google-fu fails me on this one.

because addressing
C is somewhat close to how the cpu does that

an array is a piece of memory pointed to by the address associated with its name
with its size being num_elements*sizeof(element)
ex: type array[num_elements]

the first element is right at that "array" address

to calculate the address of any element the cpu would do
array+element_num*sizeof(element)

so if element_num were to be at least 1 it would mean that either the first element was skipped or that the compiler would automatically subtract 1 from element_num

In Lua, arrays are implemented by indexing tables with integers. Due to that, an array in Lua can have any integer as base index, but common practice in Lua is indeed to have 1 as base index for arrays.

Copied from: https://en.wikipedia.org/wiki/Zero-based_numbering
APL allows each program to specify 0 or 1 as the index origin. See: http://microapl.com/apl_help/ch_020_070_380.htm

Daniel B. Martin

Fortran and Matlab both start at 1. Although with Fortran that's just the default, you can force it to start at 0 if you want, you can even force it to start at -3 or +7 if you want.

There you go. There are always exceptions!

I agree, but I have seen in books that C is a high level language. Honestly, I think it is one of the few mid-level languages, where you can use inline assembly (low level), and create functions and structs (high level). It is designed for efficiency, so counters have to start a 0.

just for fun, here is how perl handles: http://perldoc.perl.org/perlvar.html#%24[ (see the bottom of the page)

Many languages allow array-indexes to be a subrange (that does not have to start at zero), or an enumerated-type such as color. Pascal, for example ...

"C" is a high-level language in the sense that it provides hardware abstraction. Most of the Linux operating system (like the Unix operating system before it ...) is written in "C," with an accompanying /arch directory containing the architecture-specific stuff. The "C" language is designed to provide hardware abstraction, while remaining very close to, shall we say, "what the hardware can do, and the way that the hardware actually does it."

The Unix operating system was quite revolutionary, in its day, for having been programmed in "C," which was a language basically devised for that purpose. Prior to that, projects (e.g. "Multics" ... yes, "Unix = pun intended") were written very-substantially in assembly language. (That is to say, in t-h-e assembly language of t-h-e (only) model of computer that the operating system in question was designed to run on.) Unix was therefore the first operating system to be called, "portable."

The "C" language, by design and intention, has to be "very(!) broadly useful." It must be able to write "user-land" programs, in which glibc is presumed to exist, and "kernel-land" programs (device drivers and such, even the Linux dispatcher ...) in which nothing can be presumed to exist. It is certainly a testament to "C"'s design that most of the Linux system's source-code does not reside in any /arch directory. It is also a testament, both to the "C" language and specifically to the gcc/glibc implementation thereof, that the Linux operating system today runs on more than twenty radically-different hardware architectures.