Thomas Hruska wrote: > Thomas Hruska wrote: > >> Vic Wagner wrote: >> >>> We use it to hold caching information in some of our objects. >>> BTW, w/ respect to your above example, making a "guard" class which >>> locks in the constructor and unlocks in the destructor is safer in the >>> face of exceptions. >>> you also didn't unlock the mutex in your getState() methoc which means >>> that if someone wants to simply examine the state, they've also >>> "locked" access to the object (not a happy thing, usually). I'd argue >>> that getState() violates the concept of "logical constness" which is >>> what mutable was added to allow. >>> >> Quick search on 'logical constness' turned this article up: >> >> http://www.ddj.com/cpp/184403892 >> >> Now I understand some of the logic behind mutable but that doesn't mean >> it should exist. As the article seems to hint, it has limited use. And >> I still think a pure approach should be taken - if you mean const, don't >> use mutable. More people can grasp physical constness than they can >> logical constness. >> > > I lost Vic's recent response to this thread, but I wanted to reply that > I have figured out why I don't like 'mutable'. It isn't so much logical > vs. physical constness that bothers me (it does a little) as it is that > mutable has far-reaching consequences for a class. Suppose you are > adding a member function to an existing class and other functions are > declared const and access a member variable in a physical const fashion. > This new function is also being declared const but needs to modify > that variable. You can't have both physical AND logical constness in a > single class in reference to a single variable - the moment you add the > mutable keyword, all physical constness is lost where that variable is > concerned even if you don't want it to be that way. If that new member > function could declare the member variable as mutable _only for that > function_, that would be much easier for me to stomach because physical > constness would be maintained for the rest of the class. > logical constness is the ONLY meaningful constness that the users of a class should be concerned about. Physical constness is a mechanism for implementing logical constness.. You need to decide what makes an object "const". Clearly, making all the publicly accessable things appear to be unchanging would be a good start. It does NOT mean that all the bits have to remain unchanged. As for "far reaching consequences for a class" don't make me laugh. Nobody suddenly decides that since some method needs to "change a variable' (in YOUR example one in the public interface) so makes the variable mutable. People decide that perhaps they need to make a "self guarding" class (make it thread safe) from one that already exists...so the ADD a mutable mutex (to the private interface). The user will never even see it (or should they). It's an implementation detail, and one of the ideas of OO is that you can change the implementation without having users change their code (sometimes not even recompile).
[Non-text portions of this message have been removed]
