--- In [email protected], Vic Wagner <[EMAIL PROTECTED]> wrote: > > bwhartbeck wrote: > > --- In [email protected], Thomas Hruska <thruska@> wrote: > > > >> suraj_aten wrote: > >> > >>> hi ppl > >>> i'm getting error in the following prog > >>> is the prog right or is something wrong wit my compiler??? > >>> plz help me out in this > >>> > >>> > >>> > >>> #include<iostream.h> > >>> #include<conio.h> > >>> class date > >>> { > >>> mutable int str; //hope this is the right syntax > >>> public: > >>> date() > >>> { > >>> str=0; > >>> } > >>> > >>> int f() const > >>> { > >>> > >>> str++; > >>> } > >>> }; > >>> main() > >>> { > >>> date u; > >>> u.f(); > >>> getch(); > >>> } > >>> thanks a lot............. > >>> > >> Probably using an ancient compiler. getch() indicates Turbo C++ > >> > > or an > > > >> equivalently outdated Borland compiler suite. Seriously consider > >> > > using > > > >> a more recent compiler. BTW, your code lacks formatting among > >> > > other things. > > > >> I just looked up the 'mutable' keyword. Why anyone would declare > >> > > a > > > >> member function 'const' (indicating they won't modify any member > >> variables inside the function) and then go ahead and modify them > >> > > anyway > > > >> (via mutable members) is beyond me as to why it is in the Standard > >> > > in > > > >> the first place. Can't think of a good reason why it should exist. > >> > >> -- > >> Thomas Hruska > >> CubicleSoft President > >> Ph: 517-803-4197 > >> > >> *NEW* MyTaskFocus 1.1 > >> Get on task. Stay on task. > >> > >> http://www.CubicleSoft.com/MyTaskFocus/ > >> > >> > > > > Not sure of the actual implementation of the OP, but there was one > > clever, I thought, use of it that I came across. It has to do with > > the use of a mutex and getter methods. The mutex would be part of > > the class and would have the mutable keyword attached. The getter > > method would be declared as a const. The mutable on the mutex > > allows the implementation to actually 'lock' the mutex and maintain > > the const-ness of the getter method. It looks something like: > > > > class SomeMutable { > > private: > > mutable mutex_type m_theMutex; > > int m_iState; > > ... > > > > public: > > ... > > int getState() const; > > > > }; > > > > > > int SomeMutable::getState() const > > { > > lock(m_theMutex); // this normally would generate error since the > > // mutex member is being changed within a const > > // method > > return (m_iState); > > } > > > > Enjoy, Brett > > > > > > > > > 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. > > > [Non-text portions of this message have been removed] >
It was an example of mutable usage - in this case, lock() is scoped lock which released automatically as the method returned. The codelet that I was referencing used boost mutexes (www.boost.org) and I didn't want to cloud things further so removed it from the example. Obviously, agree that a mutex should be unlocked at some point prior to method exit.
