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. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
