C++ Core Guidelines: Rules for Constants and Immutability


Making objects or methods const has two benefits. First, the compiler will complain when you break the contract. Second, you tell the user of the interface that the function will not modify the arguments.

 precious 1199183 1920

The C++ Core Guidelines has five rules to const, immutability, and constexpr. Here are they:

Before I dive into the rules, I have to mention one expression. When someone writes about const and immutability, you often hear the term const correctness. According to the C++ FAQ, it means:

  • What is const correctness?  It means using the keyword const to prevent const objects from getting mutated.

Now, we know it. This post is about const correctness.

Con.1: By default, make objects immutable

Okay, this rule is quite easy. You can make a value of a built-in data type or an instance of a user-defined data type const. The effect is the same. If you want to change it, you will get what you deserve: a compiler error.


struct Immutable{
    int val{12};

int main(){
    const int val{12};
    val = 13;      // assignment of read-only variable 'val'
    const Immutable immu;
    immu.val = 13; // assignment of member 'Immutable::val' in read-only object


 The error messages from the GCC are very convincing.

Con.2: By default, make member functions const

Declaring member functions as const has two benefits. An immutable object can only invoke const methods and const methods cannot modify the underlying object. Once more. Here is a short example that includes the error messages from GCC:


struct Immutable{
    int val{12};
    void canNotModify() const {
        val = 13;  // assignment of member 'Immutable::val' in read-only object
    void modifyVal() {
        val = 13;

int main(){
    const Immutable immu;
    immu.modifyVal();  // passing 'const Immutable' as 'this' argument discards qualifiers 


This was not the full truth. Sometimes, you distinguish between the logical and the physical constness of an object. Sounds strange. Right?

  • Physical constness: Your object is declared const and can, therefore, not be changed.
  • Logical constness: Your object is declared const but could be changed.

Okay, physical constness is quite easy to get but logical constness. Let me modify the previous example a little bit. Assume, I want to change the attribute val in a const method.


// mutable.cpp

#include <iostream>

struct Immutable{
    mutable int val{12};            // (1)
    void canNotModify() const {
        val = 13;

int main(){
    std::cout << std::endl;
    const Immutable immu;
    std::cout << "val: " << immu.val << std::endl;
    immu.canNotModify();            // (2)
    std::cout << "val: " << immu.val << std::endl;
    std::cout << std::endl;


The specifier mutable (1) made the magic possible. The const object can, therefore, invoke the const method (2) which modifies val.


Here is a nice use-case for mutable. Imagine, your class has a read operation which should be const. Because you use the objects of the class concurrently you have to protect the read method with a mutex. So the class gets a mutex and you lock the mutex in the read operation. Now, you have a problem. Your read method cannot be const because of the locking of the mutex. The solution is to declare the mutex as mutable.

Here is a sketch of the use case. Without mutable, this code would not work


struct Immutable{
    mutable std::mutex m;
    int read() const {
        std::lock_guard<std::mutex> lck(m);
        // critical section


Con.3: By default, pass pointers and references to consts

Okay, this rule is quite obvious. If you pass pointers or references to consts to a function, the intention of the function is obvious. The pointed or referenced object would not be modified.


void getCString(const char* cStr);
void getCppString(const std::string& cppStr);


Are both declarations equivalent? Not one hundred per cent. In the case of the function getCString, the pointer could be a null pointer. This means you have to check in the function vai if (cStr) ....

But there is more. The pointer and the pointee could be const.

Here are the variations:

  • const char* cStr: cStr points to a char that is const; the pointee cannot be modified
  • char* const cStrcStr is a const pointer; the pointer cannot be modified
  • const char* const cStr: cStr is a const pointer to a char that is const; neither the pointer nor the pointee could be modified

Too complicated? Read the expressions from right to left. Still too complicated? Use a reference to const.

I want to present the next two rules from the concurrency perspective. Let me do it together.

Con.4: Use const to define objects with values that do not change after construction and Con.5: Use constexpr for values that can be computed at compile time

If you want to share a variable immutable between threads and this variable is declared as const, you are done. You can use immutable without synchronisation and you get the most performance out of your machine. The reason is quite simple. To get a data race, you should have a mutable, shared state.

  • Data Race: At least two threads access a shared variable at the same time. At least one thread tries to modify it.


There is only one problem to solve. You have to initialise the shared variable in a thread-safe way. I have at least four ideas in my mind.

  1. Initialise the shared variable before you start a thread.
  2. Use the function std::call_once in combination with the flag std::once_flag.
  3. Use a static variable with block scope.
  4. Use a constexpr variable.

A lot of people oversee variant 1 which is quite easy to do right. You can read more about the thread-safe initialisation of a variable in my previous post: Thread-safe Initialization of Data.

Rule Con.5 is about variant 4. When you declare a variable as constexpr constexpr double totallyConst = 5.5;, totallyConst is initialised at compile-time and, therefore, thread-safe.

That was not all to constexpr. The C++ core guidelines forgot to mention one important aspect of constexpr concurrent environments. constexpr functions are sort of pure. Let's have a look at the constexpr gcd .

constexpr int gcd(int a, int b){
  while (b != 0){
    auto t= b;
    b= a % b;
    a= t;
  return a;


First, what does pure mean? And second, what does sort of pure mean?

A constexpr function can be executed at compile time. There is no state at compile time. When you use this constexpr function at runtime the function is not per se pure. Pure functions are functions that return always the same result when given the same arguments. Pure functions are like infinitely large tables from which you get your value. The guarantee that an expression returns always the same result when given the same arguments is called referential transparency.

Pure functions have a lot of advantages:

  1. The function call can be replaced by the result.
  2. The execution of pure functions can automatically be distributed to other threads.
  3. A function call can be reordered.
  4. They can easily be refactored or be tested in isolation.

In particular, point 2 makes pure functions so precious in concurrent environments. The table shows the key points of pure functions.


I want to stress one point. constexpr functions are not per se pure. They are pure when executed at compile time.

What's next

That was is. I'm done with constness and immutability in the C++ core guidelines. In the next post, I start to write about the future of C++: templates and generic programming.




Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, espkk, Louis St-Amour, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Tobi Heideman, Daniel Hufschläger, Red Trip, Alexander Schwarz, Tornike Porchxidze, Alessandro Pezzato, Evangelos Denaxas, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Dimitrov Tsvetomir, Leo Goodstadt, Eduardo Velasquez, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, and Michael Young.


Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, and Bhushan Ivatury.



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small



I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)


Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.


Contact Me

Modernes C++,







My Newest E-Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Interactive Course: The All-in-One Guide to C++20

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code


Today 2465

Yesterday 7541

Week 25391

Month 194808

All 7462648

Currently are 164 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments