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:

Pretty straightforward stuff. If we add this code:

  x = 17;

the pictures changes to look like this:

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:

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:

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:

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.

“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.