You are here

It seems that when it comes to programming computers there is no escaping the mention of the word pointers. Recent programming language trend is to automatically handle pointers, hiding gory details from the programmer. While this might be a good language feature, will it eventually result in a new generation of programmers who do not understand pointers?

Pointers are dreaded by some programmers and loved by others and it is safe to say that there are more programmers in the first group than in the latter one. This is because for many programmers pointers have brought shame and stress in seemingly innocent looking code, and that too on more than one occasion.

While it is true that pointers have been a source for numerous problems in computer programs, closer investigation will reveal that a lot of problems that make pointers infamous are because the programmer in question never really fully understood them. They only thought that they understood pointers.

In theory, a pointer is simply a variable that holds a memory address. Pointers are not a programming language construct. Their origin is deeper than that. Internally the machine (processor) works on data, but because data is located in memory, it must also be able to understand and work on the address of the data a.k.a. A pointer. All programming languages expose data to the programmer (wrapped up in cuddly types like int, string, double), but some languages (notably C and its derivatives) also expose the address of data (wrapped up in not so cuddly types like *int, *char, *double).

All this may not seem very complicated to understand in itself. However it is crucial to understand that system memory is a treacherous and constantly changing landscape. It is limited in size and partitioned into accessible and not accessible bits. Your programs memory is located within the system memory which is in turn shared by other programs running on that system, including the OS. All this means that a pointer that points to the wrong thing will lead to certain disaster. And because in theory a pointer is such a simple concept, it is every easy to have it point to the wrong thing. On the other hand, having direct access to system memory and being able to manipulate it correctly means you can get away with some pretty nifty things.

The complexity of understanding and using pointers is essential to understanding the roots of how the machine works. Programming using pointers forces you to think about how your program behaves in the context of other programs. It forces you to think of your program as a living (eh!) dynamic entity rather than a bunch of machine instructions. This is why, in my opinion, programmers that take the trouble to really understand pointers write better code then those who do not, even if the program written does not use pointers.

So what about languages that advertise 'no pointers' or 'automatic handling' of pointers? Any serious programming language these days gets its roots from C and therefore will use pointers no matter what the tin says. It is very difficult (if not impossible) to design a effective and efficient language without using pointers. Remember that the OOP concept of Polymorphism works by resolving types at runtime and this can only be done by using pointers. What the language designers do is to wrap pointers up in different ways to effectively hide them from the programmer. However, when things go wrong in the pointer world, the language designers can no longer hide the issue and are forced to expose the pointer. Java for example does this and I have seen more often than not newbie Java programmers in their carefree world without pointers are occasionally stumped by the java.lang.NullPointerException. At which point the programmers are stunned and wiggle their thumbs in anxiety not knowing what went wrong. Little do these programmers know that while Java purports 'no pointers' every variable in Java that does not hold a basic type is actually a pointer. So they are literally working with pointers all the time under their very noses without even realizing it.

Now don't get me wrong, automatic pointer handling is a great language feature however it does not mean that the programmer is saved from understanding pointers. It does mean that a lot of new programmers are not exposed to pointers early enough and only realize their ignorance when things go badly wrong. A programmer that believes that using a pointer safe language will save them from understanding pointers will be disappointed or is probably just writing scripts, not programs. On the other hand automatic handling of pointers is a boon to programmers that really understand pointers as it saves them a lot of hassle. And when things go wrong they can still save the day because they know what is happening under the hood.

So my advice is even if you are working with a new generation language that does the pointer gimmicks for you, you should take the time to understand what it does with pointers under the hood. There is no escaping pointers. They will live as long as computer programs will. For those of you who believe they are pretty good at pointers should try out the C. Puzzle Book. In fact here is a little puzzle in C to get you started and boost your confidence:

Test Yourself

What does this program print?

char *c[]={
    "ENTER",
    "NEW",
    "POINT",
    "FIRST"
};
char **cp[]={c+3,c+2,c+1,c};
char ***cpp=cp;
main() {
    printf("%s",**++cpp);
    printf("%s ",*--*++cpp+3);
    printf("%s",*cpp[-2]+3);
    printf("%s\n",cpp[-1][-1]+1);
}