const Correctness in Function Parameters

A function usually exists to produce something. It takes inputs, does some work, and the caller needs the outcome. The most familiar route for that outcome is the return value: the function computes an answer and hands it back at the end of the call. Sometimes, though, the design calls for a different route, where the answer is delivered through one of the arguments the caller supplied. This article looks at that alternative, why it works, and when it makes sense to use it.

Keep one question in mind as you read: when a function hands information back through an argument rather than a return value, which piece of memory is actually being changed, and who ends up seeing the change?

When an argument is passed by nonconst reference, the function does not receive a private copy of the caller's data. Instead it receives a name for the caller's own object. Anything the function does to that name is done to the original object. This is the core of the technique: the function returns its result by changing the data it was given access to.

Notice what did not happen. The function did not send 50 back through a return statement, and the caller did not copy anything out of a return value. The caller's variable simply holds the new value once the function has finished, because the function changed that very object.

The reason the change is visible to the caller is that the caller's argument and the function's parameter both refer to one object. Two names, one object. The parameter is simply another way of reaching the caller's data, so writing through the parameter is writing to the original.

The technique is deliberate rather than accidental. A nonconst reference is appropriate when the job of the function is expected to include modifying the value of the data it refers to. If the function is only meant to read its input, a nonconst reference grants more power than the task needs, and that extra power is a reason to look for a different design.

A more conventional arrangement splits the jobs apart. The input data is passed by const reference, which tells the reader and the compiler that the function will only look at it. The function's output is handled by a separate argument that marks where the result should be placed. The caller creates that place beforehand, passes its location in, and the function writes the answer there.

Notice what this arrangement does to the roles of the arguments. One argument is a window onto the input, which the function must not change. The other is a destination, which the function is expected to fill. Because each argument has one clear role, a reader can tell from the parameter list alone which data is read and which data is written.

This approach is described as very common, and it works reliably. Its author does not consider returning results through arguments especially elegant, and the trade-offs are revisited later in the course. For now, treat it as a standard technique you must be able to read and reason about.

Trace the events in order when the caller passes an argument, the function modifies it, and control returns. The sequence below uses the separate-argument version from the previous section, where the caller prepares a destination and the function writes into it.

Both techniques place the result somewhere the caller can reach, but they differ in how the function is told where to put it and in what the reader can infer from the signature. The table below sets them side by side.

A useful rule of thumb follows from the source. If the task is to change the caller's data as part of its job, a nonconst reference matches the intent. If the task only reads its input, a nonconst reference grants more power than needed, so the separate-argument design, with inputs taken by const reference, is the better fit.