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, if you insist on physical constness, you canNOT write some things that need to be written I reject catagorically the assumption that const means ONLY physical constness.
> don't use mutable. More people can grasp physical constness than they can > logical constness. > I don't give a crap what "more people can grasp"... I NEED the ability to specify logical constness. I leave it to the purist to devise a mechanism. if their little brains can't wrap themselves around logical constness, then they shouldn't use mutable (problem gone). for those of use that can, we need tools. That multiple concurrent execution instances is ignored by the C++ standard is one of the real shames of C++. How they managed to miss out on one of the more important concepts in computing is, IMO, nothing short of astonishing. Then again, seeing how badly it's been butchered almost every where it's been implemented (pthreads, windows in it's entirity) I'm suspecting that those who write languages have no more concept of it than the implementors of OSs. [Non-text portions of this message have been removed]
