Const Correctness in C++ Classes

Imagine you are handed a new object and asked to call one of its member functions. The result of that call can only be sensible if the object is already in a known, usable condition. An object that has been created but never set up is in an unpredictable state, and every function that reads its data inherits that unpredictability. C++ classes deal with this moment directly, and the same design ideas also govern which functions belong inside a class and which promise not to change an object at all. Together these ideas are what the course calls const correctness in classes.

Before reading on, try this question for yourself: if a class has a function that returns the current value stored in an object, and nothing ever sets that value, what should the function return? Hold on to your answer. The rest of this article shows how the class design can make that question impossible to get wrong.

Every object is created from a class and then used by the program. The source describes an object's creation as a sequence of events. First, some code asks for a new object. Second, the class's constructor takes responsibility for initialization. Third, the object that comes out of that step is in its starting condition rather than an arbitrary one. Only after this third stage can the rest of the program safely call the object's member functions.

The diagram shows the order of interactions: the code that requests the object, the class's constructor doing the initialization work, and the resulting object that the rest of the program can then use. The important point is that the constructor sits between the request and the usable object. If initialization were handled ad hoc by whatever code happened to touch the object first, different parts of the program could see the object in different conditions.

The practical design rule from the source is to make initialization the constructor's responsibility. When that work is placed in one dedicated member function, the rest of the class can rely on objects arriving in a consistent state. Without this rule, each function in the class would have to check whether setup had already happened before doing its own work. The constructor removes that burden from every other function.

A function can be written as a member of a class, or it can be written outside the class as a standalone function. The source gives one test for choosing between them, and that test is about need rather than convenience. Make a function a member only if it needs direct access to the representation of the class. A function that must read or change the internal data of an object is a good candidate for membership. A function that can do its work using only the values it is given, without reaching into the object's internal representation, does not need to be a member, and the guidance is to keep it outside the class.

The difference shows up in what the function can see without being handed the data. A member function runs on an object and therefore has direct access to that object's stored state. A standalone function has no such built-in access, so any data it needs must be passed in as arguments. Keeping a function outside the class when it does not need the internal data keeps the class's interface focused on what truly depends on its internal representation.

An operator is a symbol such as plus or equals that a class can give a meaning to. Because one symbol can take on several implementations, the design guidance is to define operators primarily to mimic conventional usage. A reader who sees an operator applied to a class type should be able to guess its meaning from how that operator is normally understood. An operator that does something surprising, far from its usual meaning, makes the code harder to read and harder to trust.

The declaration of a function is a promise about behavior. A member function that only reads an object's state and never changes it should say so. When the function is declared const, the reader knows immediately that calling it leaves the object unchanged, which makes the code easier to reason about. The const word sits after the parameter list in a member function declaration, and it applies to the object the function is called on.

Using the Counter class with a const object, decide which of the two calls will compile before you read the answer.

The ideas in this article form one design habit. The constructor makes every new object start in a usable state, so member functions can rely on that state. The membership test keeps a class focused on functions that truly need its internal data. Operators follow conventional meanings, and symmetric operators are written as nonmember functions so both operands are treated equally. Finally, a const member function declares that it leaves its object unchanged, which lets readers and the compiler trust that promise.