Const References and Read-Only Parameters

A task usually exists to produce something, and the caller needs that something back. The most familiar route for getting an answer out of a task is the return value: the task computes an answer and hands it to the caller when it finishes. This article looks at a different route. Instead of sending the answer out through a return value, the caller supplies a reference to data that already exists, and the task writes its outcome into that data.

There are two routes by which a task can deliver a result. In the first, the task computes an answer and sends it back through its return value. The caller receives the answer as the value of the call. In the second, the caller passes in a reference to data that already exists, and the task writes its outcome into that data. The answer then arrives in the caller's own variable, even though the call itself may not have returned anything that the caller captured.

The source describes the second route as a somewhat sneaky way of returning a result. It is sneaky because the answer leaves the task by way of an input the caller handed over, which is not where most readers expect an answer to appear. The technique is not uncommon, so you will meet it in real code, even though it is not usually the first choice a careful designer reaches for.

The key to this technique is that the caller and the task do not each hold their own copy of the data. A non-const reference is another name for the same data. The caller's variable and the task's parameter both refer to one object. When the task writes into its parameter, it is writing into that one object, so the caller's variable reflects the change as soon as the task has finished.

Consider the order of events. The caller makes the call and passes its variable as the argument. The task now works on that variable through its non-const reference parameter. The task performs its computation and writes the outcome into the parameter. Control then returns to the caller, which can read its own variable and find the result already there. The caller did not have to capture a return value to receive the answer.

The source ties the decision to intent. A non-const reference should be used only when the task is expected to modify the value of the data it refers to. The non-const reference is the signal that modification is part of the job. Before choosing it, ask whether the task's purpose includes changing the data the caller provides.

The source presents a less obscure technique for the same goal. The input data is passed by const reference, so the task can read it but is not meant to change it. A second argument is then added, and this argument names the location where the result should be deposited. The task writes its answer into that location. The result is returned through a separate argument, and the task's job is to deposit the answer where the caller said it should go.

The important difference is what each argument promises. The input is marked as something the task will only examine. The result location is marked as something the task will fill. A reader can see the flow of the answer from the parameter list alone, without reading the body of the task. This clarity is the reason the source calls this route the less obscure one.

The source suggests a concrete design exercise: a task takes a list of measurements and must report their average to the caller. The example below is an original illustration of the design decision, not a source listing.

Three designs can carry an answer from a task to its caller: a return value, a non-const reference that the task writes into, and a const reference for input paired with a separate output location. Each one answers three questions differently: who holds the result, whether the input can change, and how readable the call site is.