2nd Question - const_cast and mutable

Malcolm Smart

Can anybody give me an example of why they ever made a member mutable? I know what mutable is but couldn't give a real life reason for using one (I am not one for finding a problem to meet a solution!). 2) const_cast - allows you to, for example, remove the constness from a pointer, but if that pointer points to a const item, you can't change the value of the item. So all you can do is change what the pointer is pointing to. Same question as above - can anybody tell my why they have ever const_casted a const pointer and pointed it elsewhere!?! (Yep - both interview questions....) Regards Angel ********************************************* The sooner you fall behind, the longer you have to catch up.

Jack Puppy

I've used mutables in one instance, for capturing statistical data in a test class... void MyTestClass::PerformTest() const { // Perform some test that shouldn't change the "important" member variables // Here lies the mutable statistical members if (Test was successful) _successes++; else _failures++; } I also found an example in a book (Effective C++) of a String class that caches the string length each time the length member function is called using mutables: .h -- mutable bool lengthIsValid; mutable size_t dataLength; .cpp ---- size_t String::length() const { if (!lengthIsValid) { dataLength = strlen(data); // now fine lengthIsValid = true; // also fine } return dataLength; } 2) The only time I've ever had to use const_cast (not a pointer to const data though), is when I came across a 3rd party issue... void MyClass::DoSomething(LPCTSTR lpszData) { Win32ApiCall(const_cast<LPTSTR>(lpszData)); } The Win32 call wanted a LPTSTR, even though the string wasn't changed by the function. I don't know what you'd call it - the dreaded 3rd party design flaw?

:suss: Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!

Andrew Walker

Angel1058 wrote: 1) Can anybody give me an example of why they ever made a member mutable? I know what mutable is but couldn't give a real life reason for using one (I am not one for finding a problem to meet a solution!). In general this occurs when a const object (object A) needs to call a non-const method of the mutable member variable (object B), specifically in a way that doesn't change the const-ness of the object A (did you get all that? ;) ). Generally this occurs if pretty ugly situations - one example is: http://www.boost.org/doc/html/threads/faq.html#id635597[^] From what I can remember reference counts are another example of this, the reference count still needs to be modified, even if the object is a const copy. Angel1058 wrote: 2) const_cast - allows you to, for example, remove the constness from a pointer, but if that pointer points to a const item, you can't change the value of the item. So all you can do is change what the pointer is pointing to. Same question as above - can anybody tell my why they have ever const_casted a const pointer and pointed it elsewhere!?! I can't think of a good example, but I would imagine something like the conversion of the pointer to something that allows read-only iteration through an array might be a possible answer. If someone has gone to the effort of enforcing all that const-ness I'd think three times before performing the cast. In general const_cast should be avoided in the real world.

If you can keep you head when all about you Are losing theirs and blaming it on you; If you can dream - and not make dreams your master; If you can think - and not make thoughts your aim; Yours is the Earth and everything that's in it. Rudyard Kipling

Henry miller

1: I was creating a LRU (least reciently used) cache. in pseudo code it was something like this (more complex, I left out some details): classe my_cache { public: my_cache(); ~my_cache(); bool write(int position,void *data); bool read(int position,void *data); protected: void *data; some_data_struct data_order mutable; } Because it is a LRU cache, read needs to update data_order everytime it is called to indicate that some data was used reciently. Otherwise write (from something non-const that points to this same class) might overwrite data that has been used reciently. Note that updating data_order does not change the external behavior of the class, to the user it is still const, as nothing was destroyed. Unfortunatly the real world intruded when I tried to do that: I discovered my compiler doesn't support mutable. (it is nearly 10 years old, but there is good reason we have to use it) I've never seen a need for 2, though I suppose it might exist.