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?