C++ function parameters: use a reference or a pointer (and then dereference)?

Question

I was given some code in which some of the parameters are pointers, and then the pointers are dereferenced to provide values. I was concerned that the pointer dereferencing wou

Answer 1

From a performance perspective, any competent compiler should wipe out the issue, which is highly unlikely to be a bottleneck in any case. If you're genuinely working at that low a level, assembly code analysis and performance profiling on realistic data are going to be essential parts of your toolkit anyway.

From a maintenance perspective, you really shouldn't allow someone to pass in parameters as pointers without checking them for nullity.

So you end up writing a ton of null check code, for no good reason.

Basically it goes from:

1. Create object
2. Pass in as non-const reference

To:

1. Create object
2. Get address of object
3. Pass in address
4. Check if address points to null
5. Dereference back to a non-const reference for use throughout the function

While the compiler will parse all of that junk out, the reader of the code won't. It'll be extra code to consider when extending the functions or working out what the code does. Also more code is written, which increases the number of lines that can contain a bug. And as it's pointers, the bugs are more likely to be quirky undefined behaviour bugs.

It also encourages weaker programmers to write code like this:

int* a = new int(4); // Don't understand why this has to be a pointer
int* b = new int(5); // Don't understand why this has to be a pointer
MyFunc2(a, b);
int& a_r = *a;
int& b_r = *b;

Yes, that's terrible, but I've seen it from new coders who don't really understand the pointer model.

At the same time, I'd argue that the whole "I can see whether it's going to be modified without looking at the actual header", is a bit of a false advantage, considering the potential losses. If you can't immediately tell which are the output parameters from the context of the code, then that's your problem, and no amount of pointers are going to save you. If you must have an & to identify your output parameters, may I introduce:

MyFunc2(/*&*/a, /*&*/b)

All the "readability" of the ampersand, none of the associated pointer risks.

However, when it comes to maintenance, consistency is king. If there is existing code that you're integrating with, that passes as pointers (e.g. the other functions of the class or library), there's no good reason to be a crazy rebel and go your own way. That's really going to cause confusion.