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

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.

Solution

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.