Why C Arrays Start at Zero: I Don’t Know.

Why do C arrays start at element zero? It’s probably not why you think.

Mike Hoye did a detailed investigation here: http://exple.tive.org/blarg/2013/10/22/citation-needed/

The TL;DR is that Hoye says most programmers think C has zero-indexed arrays because the creator of C chose zero for the run-time efficiency of pointer and array arithmetic. Hoye says this is wrong; he claims that C uses zero-indexed arrays because its predecessor BCPL used them, and that BCPL chose zero-indexed arrays for compile-time efficiency. (I’m not convinced by his technical arguments, by the way, but that’s beside the point I’d like to make.)

The history of zero-indexing is interesting if you enjoy reading about the history of programming languages. Otherwise it’s hardly notable.

Except.

Except you probably thought you knew why C arrays start at element zero. “Well, it’s because pointer and array math are efficient when starting at index zero.” If asked, you’d probably say it confidently, definitively, as a Fact with a Capital F. You might even be correct, but you’re only guessing.

Hoye goes on to say that programmers who think they know something as Fact without actually knowing it are living in a “mythology.” They’re fooling themselves and others.

The honest answer to “why zero?” should probably be “I don’t know.” Perhaps followed by, “I think it makes some pointer and array operations more efficient at the machine level, but I don’t know why Dennis Ritchie chose it when he created C.”

We don’t use the phrase “I don’t know” often enough. Maybe we’re afraid of being thought of as dumb or ignorant or more junior than we want to appear, or maybe we’re afraid of being found out as impostors.

Recognizing and admitting your ignorance is one of the fastest ways to learn. Recognize and admit when you don’t know something, at least to yourself.

Why did it take me 20 years of being a software engineer to realize how important this is?

I don’t know.


 

I wrote this piece for Embedded.fm (http://embedded.fm/blog/2016/2/9/why-c-arrays-start-at-zero) and am cross-posting it here.

Understanding C pointers: Part 1

As I said in “Understanding C pointers: Part 0,” I’m going to try to explain how C pointers work.

Let’s start with the basics. Here’s some simple C code:

  int x = 23;
  int y = x;


You can think of each variable as a box which holds the value of that variable. So in this example we have 2 boxes, named “x” and “y”. After these two statements execute the “x” box contains 23, and the “y” box also contains 23. The picture looks like this:
Example 1-1

Pretty straightforward stuff. If we add this code:

  x = 17;


the pictures changes to look like this:
Example 1-2

Nothing too fancy there.

Next example: let’s add a pointer into the mix.

  int x = 23;
  int y = x;
  int * p = & x;


If the * or & in the above code scare you, please take a deep breath and relax. We’ll get through this, I promise. 🙂

“x” is a variable of type integer. So is “y”. The “int *” before p means that p is a variable of type “pointer to integer” otherwise known as an “integer pointer.” Nothing magical there. The “&” before “x” can be read as the “address of x,” or “the box named x.” Which means the pointer “p” points to the box named “x”.

As in the previous examples we have a box named “x” and another box named “y”. This example adds a pointer to an integer called “p”. You can think of this pointer as simply another box, named “p”. The value in the “p” box is a pointer to another box. For the boxes “x” and “y” we can say things like “x holds the number 23,” but for the box “p” we say “p holds a pointer to the box named “x””.

A picture is worth at least a few words:

Example 1-3
Watch what happens when we add this next line to the example:

  *p = 17;


The * before the “p” tells us we’re changing the value of what “p” points to. We are not changing the value of “p” itself. The number 17 gets put wherever the value of the “p” box point to – which is the “x” box in this case. After this code runs our picture looks like this:

Example 1-4

Notice that “p” has not changed. “p” still points to box “x”. Only the value in the box that “p” was pointing to changed.

Let’s add a couple more lines to that example:

   p = & y;
  *p = 42;


The first line changes the value in the box “p” to be a pointer to the box “y”. The 2nd line changes the value in the box that “p” points to be 42. The result looks like this:

Example 1-5

Drawing these pictures may seem unnecessary, but I guarantee that drawing them will help you understand your code. Even if you understand pointers completely, when faced with a pointer-laden interview question it’s a good idea to draw your data structures and pointers. This way the interviewer can see how you’re thinking about the question, which is frequently more useful than simply getting the “right” answer.

Okay, that’s the basics. See – pointers aren’t that bad.

And it turns out that the way a computer actually implements variables/pointers is a lot like our simple “boxes” model. Tune in next time for more about that.

Understanding C pointers: Part 0

“C/C++ Pointers are evil. Ditto direct control of memory via malloc, free, new and delete. Java, C# and other ’safe’ languages are the wave of the future, man!”

Even if you shouted a hearty, “Amen, brother!” after reading those sentences, the C/C++ languages can teach you something useful. Understanding how to directly control memory with “close to the metal” languages like C and C++ can make you smarter, which is a good goal even if you won’t admit to having used such old-school languages.

Of course that new knowledge may displace other knowledge you want to retain, like Mr. Belvedere episode plot lines or your wedding anniversary. You’ve been warned.

Over the next few posts I’m going to try to explain how C pointers work. I assume you’re at least a little familiar with a C-type imperative programming language – if you’ve ever seen Pascal, BASIC, Fortran, C# or Java you should be fine.

I’ve always heard pointers introduced to students as “a difficult thing, this is hard, you won’t understand it…” – which is baloney. It’s worse than just baloney, actually – it’s spoiled baloney (or bologna, I guess), because it not only tastes bad, but also makes you sick. It sets you up for failure. Telling someone that they can’t learn something, and then attempting to teach it to them is… well, I’ll just say it’s foolish and leave it at that.

Pointers are NOT difficult to understand when explained well – I hope that I’m able to explain C/C++ pointers in an easy to understand way – please let me know if anything doesn’t make sense!

Understanding C pointers: Part 1” is now available, check it out.