I recently came across Herb Sutter's video from about how the meaning of const
and mutable
has changed in C++11 to mean bitwise const (and thread-safe, as a consequence) instead of the traditional logically const.
Five years later, have programmers migrated to this new meaning of const?
I've tried using this while writing a new application but it seems that I'm marking every private member as mutable because they're either protected by a mutex or thread-safe (by their implementation) – which doesn't feel right (I'm inexperienced and do not have a basis for this).
Is it good practice while designing a thread-safe application to mark every member function const
and every member variable mutable
?
Best Answer
The video you cited is for an advanced and expert audience. Herb Sutter tries to bring this audience to a consensus on how to best communicate the intent of these keywords to other people, in this age of everything yearning to be thread-safe.
So don't expect that this video contains all you need to know to write perfectly thread-safe code.
Here is a hypothetical example of what would be blatantly wrong:
The function signature screams wrong, because a function named
setSize
couldn't possibly beconst
. The implementation of the function's code would eventually require marking the members "x" and "y" asmutable
, which would scream wrong too.It doesn't matter what code is in the
setSize
function. If the function's name implies that the function will change the state of the object, it should not be marked withconst
. Let's suppose we remove theconst
keyword from the function. Now we find that we don't have to use themutable
keyword on the members "x" and "y". Problem solved.In other words, if the use of
const
andmutable
are both against intuition, and if such awkward usage occur in pairs, then one should to be suspicious of their usage being wrong.However, the video mentions one exceptional case. If a class contains a
std::mutex
member, it is almost always correct to mark it as amutable
member. Please refer to the video for explanations.Once you have some experience doing it correctly, you can rely on your intuition to see whether it looks natural, and natural means correct.
If a function's name implies that it should not change the state of the object, then it should be marked with
const
, and the code inside needs to be made thread-safe, by not performing thread-unsafe operations.This is the mentality expressed in the video linked above. When it comes to thread-safety, users of your code (yourself, or your fellow teammates) have certain expectations that certain functions shouldn't do certain things.
The video mentions these examples:
bool operator == (const T& other) const
should never modifythis
orother
, because nobody would expect comparisons to modify anything. (This is called "side-effect free".)class T { public: T(const T& other) {...} };
should never modifyother
, because the same instance ofother
might have been passed into two threads, each threading passing it into the copy constructor.How about this code?
This code is even better. It demonstrates the correct use of
const
on members.However, it does prevent one from using the
Size
class in certain ways. For example, you cannot use assignment operators to overwrite an existing instance ofSize
. In other words, following the best practice when implementing theSize
class, may require you to redesign other source code that usesSize
. This is the "contagious issue" that makes const-ness an important consideration for a C++ project.