How to make a data member const after but not during construction?

Question

Without relying on const_cast, how can one make a C++ data member const after but not during construction when there is an expensive-to-compute intermediate value that is needed to calculate multiple data members?

The following minimal, complete, verifiable example further explains the question and its reason. To avoid wasting your time, I recommend that you begin by reading the example's two comments.

#include <iostream>

namespace {

    constexpr int initializer {3};
    constexpr int ka {10};
    constexpr int kb {25};

    class T {
    private:
        int value;
        const int a_;
        const int b_;
    public:
        T(int n);
        inline int operator()() const { return value; }
        inline int a() const { return a_; }
        inline int b() const { return b_; }
        int &operator--();
    };

    T::T(const int n): value {n - 1}, a_ {0}, b_ {0}
    {
        // The integer expensive
        //     + is to be computed only once and,
        //     + after the T object has been constructed,
        //       is not to be stored.
        // These requirements must be met without reliance
        // on the compiler's optimizer.
        const int expensive {n*n*n - 1};
        const_cast<int &>(a_) = ka*expensive;
        const_cast<int &>(b_) = kb*expensive;
    }

    int &T::operator--()
    {
        --value;
        // To alter a_ or b_ is forbidden.  Therefore, the compiler
        // must abort compilation if the next line is uncommented.
        //--a_; --b_;
        return value;
    }

}

int main()
{
    T t(initializer);
    std::cout << "before decrement, t() == " << t() << "\n";
    --t;
    std::cout << "after  decrement, t() == " << t() << "\n";
    std::cout << "t.a() == " << t.a() << "\n";
    std::cout << "t.b() == " << t.b() << "\n";
    return 0;
}

Output:

before decrement, t() == 2
after  decrement, t() == 1
t.a() == 260
t.b() == 650

(I am aware of this previous, beginner's question, but it treats an elementary case. Please see my comments in the code above. My trouble is that I have an expensive initialization I do not wish to perform twice, whose intermediate result I do not wish to store; whereas I still wish the compiler to protect my constant data members once construction is complete. I realize that some C++ programmers avoid constant data members on principle but this is a matter of style. I am not asking how to avoid constant data members; I am asking how to implement them in such a case as mine without resort to const_cast and without wasting memory, execution time, or runtime battery charge.)

FOLLOW-UP

After reading the several answers and experimenting on my PC, I believe that I have taken the wrong approach and, therefore, asked the wrong question. Though C++ does afford const data members, their use tends to run contrary to normal data paradigms. What is a const data member of a variable object, after all? It isn't really constant in the usual sense, is it, for one can overwrite it by using the = operator on its parent object. It is awkward. It does not suit its intended purpose.

@Homer512's comment illustrates the trouble with my approach:

Don't overstress yourself into making members const when it is inconvenient. If anything, it can lead to inefficient code generation, e.g. by making move-construction fall back to copy constructions.

The right way to prevent inadvertent modification to data members that should not change is apparently, simply to provide no interface to change them—and if it is necessary to protect the data members from the class's own member functions, why, @Some programmer dude's answer shows how to do this.

I now doubt that it is possible to handle const data members smoothly in C++. The const is protecting the wrong thing in this case.

Answer 1

It's pretty easy to modify the const ints in your object as a result of a significant change in c++20. The library function construct_at and destroy_at have been provided to simplify this. For your class, destroy_at is superfluous since the class contains no members that use dynamic memory like vector, etc. I've made a small modification, added a constructor taking just an int. Also defined an operator= which allows the objects to be manipulated in containers. You can also use construct_at to decrement a_ and b_ in your operator-- method. Here's the code:

    #include <iostream>
    #include <memory>

    namespace {

        constexpr int initializer{ 3 };
        constexpr int ka{ 10 };
        constexpr int kb{ 25 };

        class T {
        private:
            int value;
            const int a_{};
            const int b_{};
        public:
            T(int n);
            T(int n, int a, int b);
            T(const T&) = default;
            inline int operator()() const { return value; }
            inline int a() const { return a_; }
            inline int b() const { return b_; }
            int& operator--();
            T& operator=(const T& arg) { std::construct_at(this, arg); return *this; };
        };

        T::T(const int n, const int a, const int b) : value{ n - 1 }, a_{ a }, b_{ b } {}
        T::T(const int n) : value{ n - 1 }
        {
            // The integer expensive
            //     + is to be computed only once and,
            //     + after the T object has been constructed,
            //       is not to be stored.
            // These requirements must be met without reliance
            // on the compiler's optimizer.
            const int expensive{ n * n * n - 1 };
            std::construct_at(this, n, ka*expensive, kb*expensive);
        }

    int& T::operator--()
    {
        // implement decrements
        //--a_; --b_;
        const int a_1 = a_ - 1;
        const int b_1 = b_ - 1;
        std::construct_at(this, value, a_1, b_1);
        return value;
    }
}

int main()
{
    T t(initializer);
    std::cout << "before decrement, t() == " << t() << "\n";
    --t;
    std::cout << "after  decrement, t() == " << t() << "\n";
    std::cout << "t.a() == " << t.a() << "\n";
    std::cout << "t.b() == " << t.b() << "\n";
    return 0;
}

Output:

before decrement, t() == 2
after  decrement, t() == 1
t.a() == 259
t.b() == 649

Answer 2

Before describing the answer, I'd first suggest you to re-think your interface. If there's an expensive operation, why don't you let the caller be aware of it and allow them to cache the result? Usually the design forms around the calculations and abstractions that are worth keeping as a state; if it's expensive and reusable, it's definitely worth keeping.

Therefore, I'd suggest to put this to the public interface:

struct ExpensiveResult
{
    int expensive;

    ExpensiveResult(int n)
    : expensive(n*n*n - 1)
    {}
};

class T
{
private:
  const int a;
  const int b;

  T(const ExpensiveResult& e)
  : a(ka * e.expensive)
  , b(kb * e.expensive)
  {}
};

Note that ExpensiveResult can be directly constructed from int n (ctor is not explicit), therefore call syntax is similar when you don't cache it; but, caller might, at any time, start storing the result of the expensive calculation.

Answer 3

One possible way could be to put a and b in a second structure, which does the expensive calculation, and then have a constant member of this structure.

Perhaps something like this:

class T {
    struct constants {
        int a;
        int b;

        constants(int n) {
            const int expensive = ... something involving n...;
            a = ka * expensive;
            b = kb * expensive;
        }
    };

    constants const c_;

public:
    T(int n)
        : c_{ n }
    {
    }
};

---

With that said, why make a_ and b_ constant in the first place, if you control the class T and its implementation?

If you want to inhibit possible modifications from other developers that might work on the T class, then add plenty of documentation and comments about the values not being allowed to be modified. Then if someone modifies the values of a_ or b_ anyway, then it's their fault for making possibly breaking changes. Good code-review practices and proper version control handling should then be used to point out and possibly blame wrongdoers.

Answer 4

Something along these lines perhaps:

class T {
private:
  T(int n, int expensive)
    : value{n-1}, a_{ka*expensive}, b_{kb*expensive} {}
public:
  T(int n) : T(n, n*n*n - 1) {}
};