Essential Books

Const Correct Class Design

suggest change

In a const-correct class, all member functions which don’t change logical state have this cv-qualified as const, indicating that they don’t modify the object (apart from any mutable fields, which can freely be modified even in const instances); if a const cv-qualified function returns a reference, that reference should also be const. This allows them to be called on both constant and non-cv-qualified instances, as a const T* is capable of binding to either a T* or a const T*. This, in turn, allows functions to declare their passed-by-reference parameters as const when they don’t need to be modified, without losing any functionality.

Furthermore, in a const correct class, all passed-by-reference function parameters will be const correct, as discussed in Const Correct Function Parameters, so that they can only be modified when the function explicitly needs to modify them.

First, let’s look at this cv-qualifiers: 

// Assume class Field, with member function "void insert_value(int);".

class ConstIncorrect {
    Field fld;

  public:
    ConstIncorrect(Field& f); // Modifies.

    Field& getField();        // Might modify.  Also exposes member as non-const reference,
                              //  allowing indirect modification.
    void setField(Field& f);  // Modifies.

    void doSomething(int i);  // Might modify.
    void doNothing();         // Might modify.
};

ConstIncorrect::ConstIncorrect(Field& f) : fld(f) {} // Modifies.
Field& ConstIncorrect::getField() { return fld; }    // Doesn't modify.
void ConstIncorrect::setField(Field& f) { fld = f; } // Modifies.
void ConstIncorrect::doSomething(int i) {            // Modifies.
    fld.insert_value(i);
}
void ConstIncorrect::doNothing() {}                  // Doesn't modify.
class ConstCorrectCVQ {
    Field fld;

  public:
    ConstCorrectCVQ(Field& f);     // Modifies.

    const Field& getField() const; // Doesn't modify.  Exposes member as const reference,
                                   //  preventing indirect modification.
    void setField(Field& f);       // Modifies.

    void doSomething(int i);       // Modifies.
    void doNothing() const;        // Doesn't modify.
};

ConstCorrectCVQ::ConstCorrectCVQ(Field& f) : fld(f) {}
Field& ConstCorrectCVQ::getField() const { return fld; }
void ConstCorrectCVQ::setField(Field& f) { fld = f; }
void ConstCorrectCVQ::doSomething(int i) {
    fld.insert_value(i);
}
void ConstCorrectCVQ::doNothing() const  {}

// This won't work.
// No member functions can be called on const ConstIncorrect instances.
void const_correct_func(const ConstIncorrect& c) {
    Field f = c.getField();
    c.do_nothing();
}

// But this will.
// getField() and doNothing() can be called on const ConstCorrectCVQ instances.
void const_correct_func(const ConstCorrectCVQ& c) {
    Field f = c.getField();
    c.do_nothing();
}

We can then combine this with Const Correct Function Parameters, causing the class to be fully const-correct. 

class ConstCorrect {
    Field fld;

  public:
    ConstCorrect(const Field& f);  // Modifies instance.  Doesn't modify parameter.

    const Field& getField() const; // Doesn't modify.  Exposes member as const reference,
                                   //  preventing indirect modification.
    void setField(const Field& f); // Modifies instance.  Doesn't modify parameter.

    void doSomething(int i);       // Modifies.  Doesn't modify parameter (passed by value).
    void doNothing() const;        // Doesn't modify.
};

ConstCorrect::ConstCorrect(const Field& f) : fld(f) {}
Field& ConstCorrect::getField() const { return fld; }
void ConstCorrect::setField(const Field& f) { fld = f; }
void ConstCorrect::doSomething(int i) {
    fld.insert_value(i);
}
void ConstCorrect::doNothing() const {}

This can also be combined with overloading based on constness, in the case that we want one behaviour if the instance is const, and a different behaviour if it isn’t; a common use for this is constainers providing accessors that only allow modification if the container itself is non-const. 

class ConstCorrectContainer {
    int arr[5];

  public:
    // Subscript operator provides read access if instance is const, or read/write access
    // otherwise.    
          int& operator[](size_t index)       { return arr[index]; }
    const int& operator[](size_t index) const { return arr[index]; }

    // ...
};

This is commonly used in the standard library, with most containers providing overloads to take constness into account.

Found a mistake? Have a question or improvement idea? Let me know.

Feedback about page:

Feedback:
Optional: your email if you want me to get back to you:

Const correctness:
* Const Correctness
* The Basics
* Const Correct Class Design
* Const Correct Function Parameters
* Const Correctness as Documentation
Table Of Contents
0 Getting started
1 Literals
2 Basic type keywords
3 Operator precedence
4 Floating point arithmetic
5 Bit operators
6 Bit manipulation
7 Bit fields
8 Arrays
9 Flow control
10 const keyword
11 Loops
12 mutable keyword
13 friend keyword
14 keywords
15 Variable declaration keywords
16 auto keyword
17 Pointers
18 Type keywords (class, enum, struct, union)
19 Classes / structs
20 std::string
21 Enumeration
22 std::atomic
23 std::vector
24 std::array
25 std::pair
26 std::map
27 std::unordered_map
28 std::set and std::multiset
29 std::any
30 std::variant
31 std::optional
32 std::integer_sequence
33 std::function
34 std::forward_list
35 std::iomanip
36 Iterators
37 Basic I/O
38 File I/O
39 Streams
40 Stream manipulators
41 Metaprogramming
42 Returning multiple values from a function
43 References
44 Polymorphism
45 Value and reference semantics
46 Function call by value vs. by reference
47 Copying vs assignment
48 Pointers to class / struct members
49 The this pointer
50 Smart pointers
51 Unions
52 Templates
53 Namespaces
54 Function overloading
55 Operator overloading
56 Lambdas
57 Threading
58 Value categories
59 Preprocessor
60 SFINAE
61 Rule of three, five and zero
62 RAII
63 Exceptions
64 Implementation-defined behavior
65 Special member functions
66 Random numbers
67 Sorting
68 Regular expressions
69 Perfect forwarding
70 Virtual member functions
71 Undefined behavior
72 Overload resolution
73 Move semantics
74 Pimpl idiom
75 Copy elision
76 Fold expressions
77 Unnamed types
78 Singleton
79 ISO C++ Standard
80 User-defined literals
81 Type erasure
82 Memory management
83 Explicit type conversions
84 RTTI
85 Standard library algorithms
86 Expression templates
87 Scopes
88 Atomic types
89 static assert
90 constexpr
91 Date and time with std::chrono
92 Trailing return type
93 Function template overloading
94 Common compile linker errors
95 Design patterns
96 Optimizations
97 Compiling and building
98 Type traits
99 One definition rule
100 Unspecified behavio
101 Argument dependent name lookup
102 Attributes
103 Internationalization
104 Profiling
105 Return type covariance
106 Non-static member functions
107 Recursion
108 Callable objects
109 Constant class member functions
110 C++ vs. C++ 11 vs C++ 17
111 Inline functions
112 Client server examples
113 Header files
114 Const correctness
115 Refactoring techniques
116 Parameter packs
117 Iteration
118 type deduction
119 C++ 11 memory model
120 Build systems
121 Concurrency with OpenMP
122 Type inference
123 Resource management
124 Storage class specifiers
125 Alignment
126 Inline variables
127 Linkage specifications
128 Curiusly recurring template pattern
129 Using declaration
130 Typedef and type aliases
131 Layout of object types
132 C incompatibilities
133 Optimization
134 Semaphore
135 Thread synchronization
136 Debugging
137 Futures and promises
138 More undefined behaviors
139 Mutexes
140 Recursive mutex
141 Unit testing
142 decltype
143 Digit separators
144 C++ Containers
145 Arithmetic meta-programming
146 Contributors