Const correctness refers to the correct use of const to indicate whether a variable or parameter shall be modified or not. Other languages may inherently make variables immutable or const by default, with a separate keyword to make them mutable: perhaps this is a safer approach. When tracing some data over many function calls, having those functions respect const correctness allows the reader to skip reading those function calls, knowing the data cannot change.
ISO CPP has a better writeup on const correctness.
In a language-agnostic setup, there is still a concept of the constness of function parameters, namely, in, out, or in-out function parameters. This is an older approach to helping document APIs so that the caller can understand how the parameters are used. I’ve seen code that looked like this:
#define IN
#define OUT
#define INOUT
struct LargeStruct { /* some large member variables */ };
/**
* @param input[in] Some input parameter
* @param in_and_out[inout] Some input and output parameter
* @param output[out] Some output parameter
*/
void foo(IN LargeStruct& input, INOUT LargeStruct& in_and_out, OUT LargeStruct& output);What if I told you there was a way to have compile-time versions of the preprocessor IN, OUT, and INOUT macros? Yes, the keyword we’re looking for is const. If a parameter is only an input parameter, then it is logically const, and can be passed by const& instead. If there is no const, then it must be either an output, or an input-output parameter. If this contract is broken by the function then it will refuse to compile. The compiler is your friend! Rewrite the above as follows:
struct LargeStruct { /* some large member variables */ };
/**
* @param input[in] Some input parameter
* @param in_and_out[inout] Some input and output parameter
* @param output[out] Some output parameter
*/
void foo(LargeStruct const& input, LargeStruct& in_and_out, LargeStruct& output);Better yet, if a parameter is only an output parameter then it can be returned from the function:
struct LargeStruct { /* some large member variables */ };
/**
* @param input[in] Some input parameter
* @param in_and_out[inout] Some input and output parameter
* @return Some output parameter
*/
LargeStruct foo(LargeStruct const& input, LargeStruct& in_and_out);I know most legacy codebases use the return value to indicate the Status of the API call, but the introduction of std::optional, std::expected, or an absl::StatusOr are much more readable alternatives – and they have other benefits, too.
If a function provides output via a non-const reference to an object, the caller is forced to add yet another line of code to declare that object as a variable in their scope. Not only is this more code to read (and write), it requires the object to be default-constructible. This may not be an issue for trivial POD types, but it is often an issue for more complex functions, such as those returning an object representing a new NetworkConnection or the like.
Furthermore, the state of a passed-by-reference object in the case of an API failure is unknown: while it is expected for the caller to not access that object, it is yet another implicit contract that adds mental overhead.
A caveat: Member Variables
There is one caveat to constness in C++: const class member variables prevents the default copy and move assignment constructors (see example). While this is sometimes annoying, it may be a good thing – perhaps if an object is given a unique identifier, it should retain that identifier even if moved-from or copied-from, and perhaps the moved-to or copied-to object should get a new identifier? That can be done by manually defining the two assignment operators.