So if pointers are so great, why not only use pointers? For two reasons, both of which are consequences of the fact that pointers are a method of indirection. Indirection is, at heart, adding a step to the set of steps needed to get at the information you need. This makes the process of getting that information more complicated.
With that complexity comes, firstly, increased risk – you have to manage memory yourself and this is fraught with peril and requires both experience and discipline. The object has to exist somewhere for a pointer to have something to point to, so you now have three things to manage – the pointer, the pointee and the relationship between them.
Secondly, the added complexity of indirection brings inefficiency. This can be inefficiency in terms of CPU cycles or in terms of memory usage. Pointers are often an unnecessary overhead e.g.
for(i=0; i<10; i++) would be overly verbose if written using pointer notation. If you’re just dealing locally with simple built-in types that don’t take up much space then there’s often little to be gained by using pointers. It’s only when you start trying to pass things around, particularly large things, that the overhead of indirection becomes smaller than the cycles or space wasted by not using it.
Because of C’s pass by value semantics, passing data into functions using parameters requires pushing and popping that data onto and off the stack, byte by byte. Using return values to pass data out of a function back to the callee also requires copying the data onto the stack.
If you’re just passing or returning an
int, then this is no big deal, but if you’re passing big data structures then all that copying can soon mount up.
The solution is to pass pointers into the function instead:
Using a pointer means passing only a few bytes rather than the whole structure. For a large array for example, instead of saying “here’s the contents of the array”, pointers allow you to say, “here’s where you can find the array already in memory”.
So, as a result of some aberrant brain misfiring you’ve decided to start learning to code in C. You pretty quickly come across the idea of functions and your mind is blown.
Then you try to write a function and all is not well. Not well at all. In fact things are looking a bit peaky. You’re not getting the output you expect. Again. Gah. Why was it that you chose C again?
After a stupidly long time spent debugging you finally narrow down the problem to what is obviously nonsensical behaviour. C is clearly broken and you’ve just discovered a fatal flaw that has gone undetected in it for the past fifty years.
This classic and frequent problem encountered at some stage by pretty much all newbies (unless of course they cheated and read the manual) is pretty much universally heralded by “WTF is my function not updating my variable?”
C passes parameters by value – it makes local copy variables of parameters passed into functions. Passing in a pointer means you get a copy of the pointer but that copy is still pointing to the original memory. Pointers are a way to bypass C’s ‘pass by value’ mechanism. Sometimes I want changes I make to be reflected in the source of the data so I need to use reference semantics through pointers. Sometimes I want to manipulate data independently of the original data so I use copy or value semantics. The difference may appear subtle but it is important – a classic and frequent problem encountered by newbies is “Why does my function not update my variable?”
Suppose you’re writing a function to double a given number. You might naively assume that this would be a reasonable solution:
If you run it you’ll find
number remains unchanged. This is, you might be surprised to discover, by design. It’s down to C’s pass by value semantics.
Instead, use referential semantics as follows to allow the
doubleIt function to have access to the
If you run this you’ll find this function works as you would hope and does indeed double the number passed to it.