Comments

Good Article. Thanks for clarifying.

Very helpful article: I just spend 3 days entangled in a debugging issue related to mutable and you have put in words what I had been sensing all the way. Thanks a lot!

Thank you for making this subject clear by presenting clean examples. =)

Thanks for clarifying 'mutable.' It's nice to know that I continue to never need it. That C++ needs keywords like 'mutable' (like 'virtual') is evidence that C++ is a terrible language.

Alan: I just read your posting, and these comments, and thought I'd add a pertinent comment. I often have to keep sets of data in memory, and typically package each "element of a set" (think struct !) as a class. Once its in a class its easy to store in a set; I just implement operator < so I know which members of the class form the "key" and which are associated data. This works nicely for me until I need to modify the class members which are not a part of the key (obviously I don't want to modify the key!). The compiler I use on our SUN machines here at work complain that I'm trying to modify a const object (the object member in the set). The VC++ compiler I ofter use for initial development doesn't complain about this. I can't decide which is worse: complaining about modifying a non-const member (the compiler can't tell which are key elements and which aren't !), or the lack of complaint (it will allow me to ruin the underlying b-tree structure by modifying a key-member? Sheesh!). I just battled through this this am, and ended up just putting the data into both sides of a map (I know! I know!). When I have a sec I'm going to explore "mutable" on the Sun side to see if it stops complaining. There's no hope for the VC++ side, as its allowing something it really shouldn't! Brooks

Nice article, I have seen the best use of mutable when dealing with classes designed to be thread-safe. Since many string and classes of the like (which are very mutable in C++ unlike Java and C#) don't handle being written to and read from at the same time very well, it is nice to have thread synchronization features of the OS to prevent corruption, problem is, without mutable... const functions can't manipulate these structures. To Andrei MR: Java does on the other hand have some point in making the class define the constness of an object rather than the methods, but it also limits the possibilities. Doesn't make either a better languages, just like C++ requires the nasty looking dynamic_cast when trying to reproduce even Java's one class multiple interfaces inheritance if both a base class and a implemented interface have the same base. Java can handle this with nicer looking code and probably better than C++.

Shouldn't Employee::promote lack the const keyword?

The article is good. This topic is also very well explainded into the B.Strustrup book.

For the people that are saying that mutable makes C++ a bad language: "That C++ needs keywords like 'mutable' (like 'virtual') is evidence that C++ is a terrible language.", I want to expalin them that this is the oposite.

Mutable makes C++ a better language. Let me explain that:

An object saves two type of information: 1.- The logical information. For instance in the Employ object, it stores all the information thas has to be with an employ (name, telephone, etc.) 2.- The internal funcional information. This is memory that is stored into the object to make that the object work well into the program. For instance gc: garabage collector pointers, the pi number (good example), counters for debuger and others. All of this information do not have realition with the employ abstract idea. It is used to make the house keeping of the program.

Well, when you instruct that and object is constant, normally you are trying to keep constant the abstract idea of what is an employ but you don't have any problem if the internal house keeping information is changed. Without this change the gc will not function for example, or you can reallocate the object in other place of memory and this needs to change some internal pointers, intrusive list pointers, etc.

This is were the mutable keywords take place. When a programmer reads that a variable is mutable, he knows that this variable is not part of the abtract representation of an employ. On the contrary, he knows that this variable is beeing used to sustaint that object Employ into the program and this information can change for internal reasons without altering the employ information.

mutable was not necesary in the past becasu you can cast a memory to be not constant and then modify it. However, C++ has the mutable keyword because this makes the intention of the programmer more clear for the reader informing he that this memory is used only for internal functionality only. Don have nothig to do with the employ.

This makes C++ a better language! Because you can write preciselly what variables are part of the employ information (abstract idea) and what variables are for internal function only (how the object it is hose keept).

Regards.

Great analysis. I agree to using it sparingly. I would like to add one common usage for mutable that I have found. Mutexes. If I have a class and I want to call a Get method for a parameter, I want that method to be const because I would like to make sure a Get method does not modify any data in the class even non-const data. So I make the method const for protection, but if this class is used accross threads I want to use the mutex that is part of my class. Unfortunately because the method is const it will not let me lock the mutex that is a member variable for that instance. This is where you use mutable. Make the mutex mutable so that you can have the protection of the const and the thread-safeness the mutex provides.

class CTest
{
public:
    Test() : m_X(0) {};
	void SetX(const int x)
	{
		m_Mutex.lock();
		m_X = x;
		m_Mutex.unlock();
	}
        // Make const because we want to protect all member variables
	int GetX(void)const
	{
		int x;
		m_Mutex.lock();
		x = m_X;
		m_Mutex.unlock();
		return(x);
	}
private:
	int m_X;
	// Mutable to protect data in const methods.
	mutable CMutex m_Mutex;	
};

Rick, m_Head does not need to be mutable in your example. In fact it defeats the purpose of making int Read() const. You want read to be const and m_Head to be const in the read method. You want don't want m_Head to be const in the Write() method. This means your declaration of void Write(int sample) is correct and should not be const. By making m_Head mutable you can modify m_Head in both the Read method and the ReadFromBuffer() method, both are probably bad ideas. Generally you don't expect read methods to be able to modify anything.

You have to use some sort of sync method to make it thread safe. 1) use mutexes or semaphores 2) disable interrupts 3) Only allow one thread to modify the data by asking what thread you are on and then firing off a call-back if you are not running on the right thread.

Mutable does not get around any thread-safe issues.

LTrain, while mutexes are a good use case for "mutable", your particular example does not actually require a mutex unless you're on a rather weird architecture where reading or writing an int is not an atomic operation.

nimble you are completely correct. That was just for an example. Although if x was not an int and was a large struct or some large object then the reads and write would be done by the compiler inserting a call to _memcpy() behind the scenes or even a call to an implicit or explicit copy constructor. This means to read or write more than one word it will take multiple cycles. In that case you would not want to do a read half way through a write and get inconsistent data. The code above was to demonstrate the concept.

I hate to necro-comment this blog, but it's pretty high up on Google's radar for "mutable keyword" and I just learned the common definition (and apparently the conception of mutable) is very off base... and I'm personally fairly put off and need to vent / ask questions.

MSVC defines mutable as (This keyword can only be applied to non-static and non-const data members of a class. If a data member is declared mutable, then it is legal to assign a value to this data member from a const member function)

I haven't tried to find formal specs, but this is incredibly misleading. It is also what I always assumed mutable does. ie. "it is legal to assign a value to this data member from a const member function"

Instead the MSVC compiler lets anything (with access privileges) at anytime assign a value to a mutable member (of a const object)

Ever sense I've been using mutable I've been assuming the member for a const object could only be changed from inside the object's const member functions.

Not so. I'm bummed. Anyone know what the spec says, or just off the top of your head if other compilers treat mutable differently (doubtful) from MSVC?

PS: This means mutable is useless outside of private/protected members... which really tend to just make internal code really circuitous. I hope future specs could remedy this.

For the record, I've sent an email to the standards secretary:

--------------------------------------------

I discovered the mutable keyword only a couple years ago, and used it only in some particular situations, for purposes which I thought left objects to be readonly (ie. const)

Though I don't believe the formal specifications for standard C++ are readily/freely available online, most resources seem to describle the keyword something like this...

"This keyword can only be applied to non-static and non-const data members of a class. If a data member is declared mutable, then it is legal to assign a value to this data member from a const member function." (taken from MSVC documentation)

I read this, and thought groovy... now I can pass an object as readonly, but still have some option of modifying some members during const member function calls. This I believe is how the mutable keyword SHOULD work (let us pray)

However I discovered today, that my objects passed as const are actually not safe. Call me daft or whatever for not noticing before (no one called me on it ever) but I learned after considerable investment in this keyword, that members declared as mutable in fact can be altered at anytime by anything (barring access declarations)

This is a nightmare, ney a travesty. Why is it an object apparently const, should contain non-const members. Any foreign const function can modify my mutable members (which are probably very important internal variables) ...and if not maliciously, on accident. Would it not make a world more sense to limit the modification of mutable variables for const objects to their own const member functions?

Please find a pertinent argument for me, and please consider changing the function of the mutable keyword in future C++ specifications (with oldstyle back compatibility via compiler options or other inline directives)

sincerely,

A concerned programmer in crisis

Mick,

you can get all kinds of side effects of C++ features, if you are not careful with those. That includes implicit virtual functions, non-trivial constructors (constructors that are not "explicit") causing implicit conversions, even overload resolution, etc. The only way to get it right is to get it right, which usually happens if you experience it yourself or hear somebody else's experiences.

The mutable keyword has its own use. If you think it's dangerous, don't use. Many software companies don't use templates, because they think it's easy to use them wrong (by abusive programmers). Similarly, some don't ban multiple inheritance completely.

@Mario : Nice comment - it's definitely about enforcing the right discipline in development teams.

Mutability should be concealed in implementation of the class by having const [public] member function(s) modifying mutable variables

@Jason: I think Mick's complain is not only about the fact that mutable does what it does, but about the lack of documentation thereof. The latter complain has merits I think.

To me the original article proves that the author does not live or work in the real world.

Const correctness is highly desirable, but in the real world we often inherit (in the physical sense) interfaces and legacy code for which are are rarely permitted to meddle.

As some other commentators have alluded, mutable is sometimes necessary to store internal states and housekeeping values when programming to an imutable interface.

A good example is ostream. Ostream may not be used as a const as it itself requires internal state management. So I might use an ostream as a mutable member of a const class if I was forced to.

Other examples include counters, iterators and states used exclusively internally.

All I can say is thank god for mutable.

So, the keyword mutable means "read only access are promoted to read write access." The keyword const means "read only access". Think of a read-only SMB or NFS access to a filesystem that is mounted read-write and is repeatedly modified by something else.

Now, is there a keyword in C++ which stands for "read only access giving constant results that can be cached" ? Think of an immutable storage, as a CDROM.

To illustrate the keyword mutable, think of a "nfs client kernel module" which, even in the case of read-only access, does stealthy things as collecting statistics and/or reordering read requests.

So, to abbreviate:

const means read-only.

mutable means stealthy.

I want a keyword which means constant.

test

Good article thanks. I've never needed mutable and it bugged me that I didn't quite understand it, but your examples cleared that up nicely.

I can think of a REALLY GOOD USE for the keyword, "mutable".

It is on a Job Interview Question.

Before that, I'd never heard of it, can't think of any time I'd use it. Thus my Web search, leading me here. Great article, btw.

Otherwise, I'm inclined to agree with the idea that, if you want it to be constant, declare it as such, otherwise don't. Simple.

thanx for d article.great help.at least from somewhere am i gettin the true concept. Jst those examples (program codes) were a bit high for my level cant they be somwhat simpler

when you marked the data member _name as const and encapsulate that, then you lost some future functionality (e.g., setname() ). and the code may not be as reusable for another project. as you say, if the object is instantiated as const, nothing can be changed, unless explicitly marked mutable. for a non-critical data member, this may be exactly what the programmer desires. if you code the data-member as const, well that's what you get, no matter how you instantiate the object. it just depends what you want to do.

when you marked the data member _name as const and encapsulate that, then you lost some future functionality (e.g., setname() ). and the code may not be as reusable for another project. as you say, if the object is instantiated as const, nothing can be changed, unless explicitly marked mutable. for a non-critical data member, this may be exactly what the programmer desires. if you code the data-member as const, well that's what you get, no matter how you instantiate the object. it just depends what you want to do.

I appreciate your up to the point article. Noobs usually abuse mutable , or the think it is an "interview question", somebody putting it down for them is very nice

I appreciate your up to the point article. Noobs usually abuse mutable , or the think it is an "interview question", somebody putting it down for them is very nice

Many thanks for the great article!

Why you says following use of mutable is incorrect & defeats purpose of const in C++?

const Employee john("JOHN","007",5000.0); .... .... john.promote(20000.0);

Please explain more about this

Bhaylu, if you're promoting john, you're changing his state. If you're changing his state, you're not treating him as constant and you shouldn't have declared him such.

Nice points. Enforcement of const is all the more important with massive threading and multiprocessor architectures being the direction computer programming is going these days.

You missed a spam posted on 6:07 Jun 7, 2008, I think.

Good overview on the "old" meaning of const + mutable until C++11. (Starting with C++11 const => thread safe; see e. g. Herb Sutter's posting + Video on Sutter’s Mill. So you should think more than twice before you use mutable to implement caching or some kind of lazy algorithm as part of a const method.)

Regards,

Thomas