不久前，我遇到了一些代码，它们用mutable关键字标记了一个类的成员变量。据我所知，它只是允许你在const方法中修改变量:
class Foo
{
private:
mutable bool done_;
public:
void doSomething() const { ...; done_ = true; }
};
这是唯一的使用这个关键字还是有更多的它比满足眼睛?从那以后，我在一个类中使用了这种技术，将boost::mutex标记为mutable，允许const函数出于线程安全的原因锁定它，但是，说实话，这感觉有点hack。
当前回答
关键字'mutable'实际上是一个保留关键字。它通常用来改变常数变量的值。如果你想要一个常量的多个值，使用关键字mutable。
//Prototype
class tag_name{
:
:
mutable var_name;
:
:
};
其他回答
它允许区分按位的const和逻辑的const。逻辑const是指对象没有以通过公共接口可见的方式更改，就像锁定示例一样。另一个例子是一个类，它在第一次请求时计算一个值，并缓存结果。
因为c++11 mutable可以用在lambda上，表示用value捕获的东西是可修改的(默认情况下不是):
int x = 0;
auto f1 = [=]() mutable {x = 42;}; // OK
auto f2 = [=]() {x = 42;}; // Error: a by-value capture cannot be modified in a non-mutable lambda
它在有隐藏内部状态(如缓存)的情况下非常有用。例如:
class HashTable
{
...
public:
string lookup(string key) const
{
if(key == lastKey)
return lastValue;
string value = lookupInternal(key);
lastKey = key;
lastValue = value;
return value;
}
private:
mutable string lastKey, lastValue;
};
然后可以让一个const HashTable对象仍然使用它的lookup()方法，该方法修改内部缓存。
当你重写一个const虚函数并想要修改该函数中的子类成员变量时，mutable可以很方便。在大多数情况下，您不希望更改基类的接口，因此必须使用自己的可变成员变量。
Mutable is used when you have a variable inside the class that is only used within that class to signal things like for example a mutex or a lock. This variable does not change the behaviour of the class, but is necessary in order to implement thread safety of the class itself. Thus if without "mutable", you would not be able to have "const" functions because this variable will need to be changed in all functions that are available to the outside world. Therefore, mutable was introduced in order to make a member variable writable even by a const function.
指定的可变变量通知编译器和读取器 成员变量可以在const中修改，这是安全和预期的吗 成员函数。
对于那些对用户来说是逻辑上无状态的东西(因此在公共类的api中应该有“const”getter)，但在底层实现(你的.cpp中的代码)中不是无状态的东西，使用“mutable”。
The cases I use it most frequently are lazy initialization of state-less "plain old data" members. Namely, it is ideal in the narrow cases when such members are expensive to either build (processor) or carry around (memory) and many users of the object will never ask for them. In that situation you want lazy construction on the back end for performance, since 90% of the objects built will never need to build them at all, yet you still need to present the correct stateless API for public consumption.
