C++ Functions – Why Not All Function Parameters Should Be References

A reference serves one purpose: to act as an alias for an existing variable:

int i;
int &ri = i;

In this example, the addresses of i and ri are identical (&i == &ri). The two names refer to the very same location in memory. Thus one of the useful applications of references is to provide an alias for a long name that it would be wasteful to retype:

const Location& p = irresponsibly_long_object_name.retrieve_location();

When you pass a function parameter by reference, it has the same effect:

void increment(int& parameter) { ++parameter; }

int main(int argc, char** argv) {
    int variable = 0;
    increment(variable);
}

Here, parameter serves merely as an alias of variable, just as though it were defined as int& parameter = variable. Modifying parameter inside increment() is indistinguishable from modifying variable in main(). Furthermore—and this is quite useful—variable does not need to be copied; so if it were of a large type such as std::list<int>, then passing it by reference would be much more efficient. That’s the main point of const references.

For the purpose of function parameters of reference type, the sanest course of action for a compiler is to use a pointer internally, as if you had written:

void increment(int* parameter) { ++*parameter; }

int main(int argc, char** argv) {
    int variable = 0;
    increment(&variable);
}

This is an interesting detail, and well worthwhile to remember. While it is not essential to your understanding of references, recognising this equivalence allows you to think of pointers merely as explicit references. Likewise, references are implicit pointers.

In theory, loose function-data coupling makes it easier to add more functions to work on the same data. The down side is it makes it more difficult to change the data structure itself, which is why in practice, well-designed functional code and well-designed OOP code have very similar levels of coupling.

Take a directed acyclic graph (DAG) as an example data structure. In functional programming, you still need some abstraction to avoid repeating yourself, so you're going to make a module with functions to add and delete nodes and edges, find nodes reachable from a given node, create a topological sorting, etc. Those functions are effectively tightly coupled to the data, even though the compiler doesn't enforce it. You can add a node the hard way, but why would you want to? Cohesiveness within one module prevents tight coupling throughout the system.

Conversely on the OOP side, any functions other than the basic DAG operations are going to be done in separate "view" classes, with the DAG object passed in as a parameter. It's just as easy to add as many views as you want that operate on the DAG data, creating the same level of function-data decoupling as you would find in the functional program. The compiler won't keep you from cramming everything into one class, but your colleagues will.

Changing programming paradigms doesn't change best practices of abstraction, cohesion, and coupling, it just changes which practices the compiler helps you enforce. In functional programming, when you want function-data coupling it's enforced by gentlemen's agreement rather than the compiler. In OOP, the model-view separation is enforced by gentlemen's agreement rather than the compiler.