If there’s one thing that scares people more than void, it’s got to be pointers. And rightfully so if they’re misused or you get somebody trying to explain them who’s already uncomfortable with them. This episode is going to rip the bandage off quick so we can move past this topic and soon you’ll wonder what all the fuss was about. I mean, really, we point to things all the time. Computers are just copying what we’ve been doing since childhood.
You’ll learn how simple index cards with a location of an item can be thought of as pointers and the benefits of adding this extra level of indirection. Because with pointers, you can now organize your items one way yet find the items with a different system.
If you get the chance, check out the Fundamental Theorem Of Software Engineering. It’s not really a theorem but it states that:
We can solve any problem by introducing an extra level of indirection.
In the podcast, I show you how to solve the problem of rearranging items on shelves while still being able to find the items. A system of pointers adds the extra layer of indirection needed.
Listen to the full episode or read the full transcript below.
Transcript
Have you ever setup a forwarding address? People who don’t yet know your new address can continue to find you through your old address. This is a pointer because your old address now points to your new address. This is also a temporary pointer because eventually it will go away. The post office only gives you about 6 months. It has to go away because while it points to your new address, it also exists as the current address for whoever is now living at your old address. Because of this dual purpose, it’s not really a good example of pointers in programming. I mentioned it to get the explanation going and because it’s an obvious analogy that has some flaws.
So what’s a pointer then in computer programming? Or what would be a better example of a pointer?
Let’s go back to the rows and shelves of the last episode and imagine that you have a small part called a super widget. The super widget fits in a square box about 5 inches per side. Let’s also say that this part is rarely needed so you keep it somewhere at the back. You sometimes get phone calls asking if you have this part or that part and you think to yourself, “There’s got to be a better way to find out if we have a part than by walking to the row and shelf and looking.” Even organizing the parts so you can find them doesn’t help eliminate the long walk to check the availability of super widgets. But it’s the best you can do, right? At least you know exactly where to find each part.
Then one day, you receive a new shipment of 3 super widgets and discover that the manufacturer decided to put them in bigger boxes. You need more shelf space because everything is already packed as tight as possible. You can’t just put the super widgets on a nearby empty shelf because that would mess up your careful system to be able to find them later. You’re in for a long week because you’re going to need to shift all the other parts in the same row over by just an inch to make room. And to make matters worse, you just went through a similar chore 2 weeks ago. Come to think about it, this has been an ongoing problem.
You look at that empty shelf again and wonder.
What if you could just put parts anywhere?
Just find a spot that fits and use it. You’d still need some way to organize the parts so you could find them but does the organization really need to be based on the actual location of the parts? You have an idea and go get a bunch of small index cards and make a note on one of them that the super widgets are on row 27, shelf 4. Then you start recording the other parts each on a separate index card. You record each part’s location and as an afterthought, since you’re at it anyway, you record how many you have.
It takes a while to record all the parts. But now, you can organize the cards however you want without needing to touch the shelves. Each card points to a specific location in the shelves where the part can be found. And each card is dedicated to point to a single part. These are pointers.
It’s not until a few days later that you realize that your new system has another benefit. You get a call asking if you have any super widgets and think, “Where did I put those super widgets?” You find the card that says they’re on row 27, shelf 4 and start walking back to see if there are any there. Halfway there, you stop, look down at the card again and notice the line that says, “Count 3.” You smile and walk back to the phone. That’s the last time you ever need to walk to a part just to check how many you have.
Just to be clear, only the information on the card that points to the location of the parts is the pointer. The count of each part is just some extra information that you thought to write down at the same time. It’s very useful but you don’t need it if all you are trying to determine is if there are ANY of those parts or not. You realize that when you run out a part, you don’t need to throw away the card, you can just erase the row and shelf information. In other words, you just need to make the address of the part point to nothing. A pointer to nothing means that you have none of those parts. A pointer to nothing is also called a null pointer and uses the special memory address zero for this purpose. This is not the same thing as a void pointer. With a null pointer, you still know what type of thing the pointer could be pointing to. It just happens to currently not point to anything. But a void pointer has no type. You don’t know what a void pointer points to. A void pointer could also currently point to nothing. That would make it a null void pointer.
If you have a valid address and somebody calls to ask if you have 2 super widgets, that’s where the count comes in handy. Because without the count you could only tell if there are zero or some other amount.
That’s it for pointers on this episode. There’s a couple more aspect of pointers that will be in the next episodes but you’ve already got the basics.