Constant Member Functions & Constant Objects

Programming Language & Its Applications — C++ Constructs with Objects and Classes, NEC licence examination syllabus (Nepal Engineering Council).

Constant Member Functions and Constant Objects

A compile-time promise not to modify — and the reason it must spread through your whole class.

🌍 Where this lives: const-correctness is what lets a compiler catch a whole bug class before your program ever runs. When a function signature says const std::string&, you know without reading the body that your string is safe — and the compiler enforces it. This matters most in multithreaded code: a genuinely const object can be read by many threads simultaneously with no lock at all, which is why Rust built its entire concurrency safety on the same distinction (&T versus &mut T) and made it unbreakable. Search "const correctness why it matters" and then "Rust shared mutable state" — you will see the same idea taken to its conclusion.

The three places `const` appears

class Circle { double r; public: double area() const; ← 1. const MEMBER FUNCTION promises not to modify *this void setR(double x) { r = x; } }; const Circle c(5); ← 2. const OBJECT only const members callable on it void f(const Circle &c); ← 3. const REFERENCE / POINTER PARAMETER same restriction applies THE MATRIX: non-const object const object non-const member ✔ ✗ const member ✔ ✔ So a const object can only call const members. If area() were not marked const, this fails: const Circle c(5); c.area(); error: passing 'const Circle' as 'this' argument discards qualifiers Under the hood: a const member function receives `const Circle * const this`, so every member reached through it is const.

const_basics.cpp

#include <iostream>

class Rectangle {
    double w, h;
public:
    Rectangle(double a, double b) : w(a), h(b) {}

    /* read-only: mark const */
    double area()      const { return w * h; }
    double perimeter() const { return 2 * (w + h); }
    double width()     const { return w; }

    /* modifies: must NOT be const */
    void scale(double f) { w *= f; h *= f; }

    /* a const function CANNOT modify members */
    /* double bad() const { w = 0; return w; }
       error: assignment of member 'Rectangle::w' in
              read-only object                        */
};

/* const& parameter: the caller's object is guaranteed safe */
void report(const Rectangle &r) {
    std::cout << "  area=" << r.area()
              << " perim=" << r.perimeter() << "\n";
    /* r.scale(2);  error: scale() is not const */
}

int main() {
    Rectangle a(4, 5);
    report(a);
    a.scale(2);              /* fine: a is not const */
    report(a);

    const Rectangle b(3, 3);
    report(b);               /* only const members used */
    std::cout << "  b.width() = " << b.width() << "\n";
    /* b.scale(2);  error: b is const */
    return 0;
}
Output:
  area=20 perim=18
  area=80 perim=36
  area=9 perim=12
  b.width() = 3

Checking: 4 × 5 = 20, 2(4+5) = 18 ✔ after scale(2): 8 × 10 = 80, 2(8+10) = 36 ✔ 3 × 3 = 9, 2(3+3) = 12 ✔ Note scale(2) doubled BOTH sides, so the area quadrupled (20 → 80) while the perimeter merely doubled (18 → 36). Area scales with f², perimeter with f — a useful check that the code does what the geometry says.

const objects and mandatory initialisation

A const object must be fully initialised at creation, because you can never assign to it afterwards. const Rectangle a; ✗ unless a default ctor exists const Rectangle b(3, 4); ✔ const Rectangle c = b; ✔ copy construction b = c; ✗ error: no operator= on a const object const MEMBERS of a class must be in the initialiser list: class Config { const int maxUsers; const std::string name; public: Config(int m, std::string n) : maxUsers(m), name(std::move(n)) {} ✔ only way /* Config(int m) { maxUsers = m; } ✗ */ }; A side effect worth knowing: a class with a const member has no implicit copy ASSIGNMENT operator (you cannot assign to the const member), so such objects can be copy-constructed but not assigned. That silently makes them unusable in std::vector operations that need assignment — a real surprise the first time it happens.

Worked example — const overloading

const_overload.cpp

#include <iostream>
#include <stdexcept>

class Array {
    int  data[5];
    int  n = 5;
public:
    Array() { for (int i = 0; i < 5; i++) data[i] = (i+1)*10; }

    /* TWO overloads differing ONLY in constness.
       This IS a valid overload — the hidden this parameter
       has a different type. */
    int& at(int i) {                    /* non-const version */
        std::cout << "  [non-const at]";
        if (i < 0 || i >= n) throw std::out_of_range("bad");
        return data[i];                 /* WRITABLE */
    }
    const int& at(int i) const {        /* const version */
        std::cout << "  [const at]";
        if (i < 0 || i >= n) throw std::out_of_range("bad");
        return data[i];                 /* READ-ONLY */
    }

    void show() const {
        for (int i = 0; i < n; i++) std::cout << data[i] << " ";
        std::cout << "\n";
    }
};

int main() {
    Array a;
    const Array b;

    std::cout << "a.at(2) reading:";
    std::cout << " " << a.at(2) << "\n";

    std::cout << "a.at(2) writing:";
    a.at(2) = 999;                  /* assign THROUGH the call */
    std::cout << "\n";
    a.show();

    std::cout << "b.at(2) reading:";
    std::cout << " " << b.at(2) << "\n";
    /* b.at(2) = 5;  error: assignment of read-only
                       location — the const overload
                       returns const int&            */
    return 0;
}
Output:
a.at(2) reading:  [non-const at] 30
a.at(2) writing:  [non-const at]
10 20 999 40 50
b.at(2) reading:  [const at] 30

This is exactly how the standard library works: std::vector<int> v{1,2,3}; int& operator[](size_t); /* v[0] = 5 ✔ */ const int& operator[](size_t) const; /* read only */ std::string s = "abc"; char& at(size_t); const char& at(size_t) const; begin() / end() also come in pairs, returning iterator or const_iterator. The rule the compiler follows: on a non-const object the non-const overload is a better match, so it wins. On a const object only the const overload is viable. Why both are needed: the non-const version returns a writable reference so `v[i] = x` works; the const version must return a const reference so read-only access is still possible on a const object. Providing only one breaks half the use cases.

Const overloading is one of the few places C++ overloads on the hidden parameter rather than a visible one. That is why int f() and double f() are illegal overloads while int f() and int f() const are legal — the second pair genuinely differ in their parameter list, once you remember this is a parameter.

mutable — the deliberate escape

mutable_cache.cpp

#include <iostream>
#include <cmath>

class Polygon {
    double sides[4];
    int    n = 4;

    /* mutable members MAY be modified in const functions.
       Used for things that are not part of the object's
       logical value: caches, counters, mutexes. */
    mutable bool   cacheValid = false;
    mutable double cachedPerimeter = 0.0;
    mutable int    computeCount = 0;

public:
    Polygon(double a, double b, double c, double d)
        : sides{a,b,c,d} {}

    double perimeter() const {
        if (!cacheValid) {
            ++computeCount;
            cachedPerimeter = 0;
            for (int i = 0; i < n; i++) cachedPerimeter += sides[i];
            cacheValid = true;
            std::cout << "  (computed)";
        } else {
            std::cout << "  (cached)  ";
        }
        return cachedPerimeter;
    }

    void setSide(int i, double v) {
        sides[i] = v;
        cacheValid = false;        /* invalidate */
    }
    int computations() const { return computeCount; }
};

int main() {
    const Polygon p(3, 4, 5, 6);
    std::cout << " perim=" << p.perimeter() << "\n";
    std::cout << " perim=" << p.perimeter() << "\n";
    std::cout << " perim=" << p.perimeter() << "\n";
    std::cout << "computed only " << p.computations()
              << " time(s) for 3 calls\n";
    return 0;
}
Output:
  (computed) perim=18
  (cached)   perim=18
  (cached)   perim=18
computed only 1 time(s) for 3 calls

The distinction mutable formalises: PHYSICAL constness — no byte of the object changes LOGICAL constness — the object's observable VALUE does not change perimeter() modifies bytes (the cache) but not the value: every call returns the same answer, and no caller can tell whether it was computed or cached. That is logically const, and mutable is how you say so. Legitimate uses of mutable: ✔ memoisation caches, as above ✔ a std::mutex member (locking is not a value change) ✔ hit/miss counters and instrumentation ✔ lazily-loaded data Abuse of mutable: ✗ making a member writable because a const function "needs" to change it — that means the function should not be const Note the cost: 3 calls, 1 computation. For an expensive operation on a large object that is the difference between O(n) per call and O(n) once.

Const propagation and pointer constness

Read pointer declarations RIGHT TO LEFT: int *p; pointer to int *p = 5 ✔ p++ ✔ const int *p; pointer to CONST int *p = 5 ✗ p++ ✔ int *const p; CONST pointer to int *p = 5 ✔ p++ ✗ const int *const p; const pointer to const int *p = 5 ✗ p++ ✗ `const int *p` and `int const *p` are IDENTICAL. The const binds to what is on its left, unless there is nothing there, in which case it binds right. SHALLOW constness — an important gotcha: class Holder { int *data; public: void modify() const { data[0] = 99; } ← LEGAL! }; The const protects the POINTER (data cannot be reseated), not what it points TO. So a const member function can freely modify the pointed-to array. C++'s const is shallow, and this is a real hole in the guarantee. void reseat() const { data = nullptr; } ✗ error void write() const { data[0] = 99; } ✔ allowed If you want deep constness you must express it yourself, usually with a const overload returning const int*.

🌍 Go further: the shallow-constness hole above is exactly what Rust closed, and it is why Rust can guarantee data-race freedom while C++ cannot. But C++ has its own more powerful tool now: constexpr, which does not merely promise not to modify — it demands the function be evaluable at compile time. A constexpr factorial produces a literal in the binary with no runtime work at all, and C++20's consteval makes that mandatory rather than optional. Search "constexpr vs const C++" — they look similar and do completely different jobs, and the difference is a common interview question.

💡 Exam angle: draw the const object / const member function matrix — a const object can call only const members. Know that a const member function receives const T* const this, which is why it cannot modify members. Const overloading (the same function name with and without const) is a favourite question — use operator[] as the example. Explain mutable as logical versus physical constness with a cache. Also be ready to read the four pointer-const forms right to left.

Syllabus points

const member functions & objects

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.