I still remember what it was like, as a C programmer, to be introduced to the newfangled concept of references in C++. I thought: “This is dumb. It’s just another way to use pointers. More syntactic sugar for no good reason…”
For a long time, I thought of pointers vs. references as a stylistic choice, and I’ve run into lots of old C pros who feel the same. (The debate on this comment stream is typical.) If you’re one of them, let me see if I can explain why I now think I was wrong, and maybe convince you to use references where it makes sense. I won’t try to enumerate every reason–just hit a few highlights.
1. References have clearer semantics
NULL
is a perfectly valid value for a pointer, but you have to do some headstands to create a reference to NULL
. Because of these headstands, and because testing a reference for NULL-ness is a bit arcane, you can assume that references are not expected to be NULL
. Consider this function prototype, typical of so much “C++” code written by folks with a C mindset:
void setClient(IClient * client);
With only that line, you don’t know very much. Will client’s state change during the call? Is it valid to pass NULL
? In the body of the call, will client ever point to anything other than the value it had at the top of the function?
Veteran C programmers recognize that the semantics are unclear, so they come up with doc conventions to plug the gap, and they check assumptions at the top of the function:
/** * @param client IN, cannot be NULL */ void setClient(IClient * client) { if (client != NULL) { //...do something
This is fine, except why depend on a comment and a programmer’s inclination to read and obey, when you can enforce your intentions at compile time, and write less code, too? Continue reading