const_cast

[strike86]

trying to understand the usage of const_cast
const char* text="bb";
(const_cast<char&>(*text))='a';
cout<<*text;
Generate runtime error ,

another question , in memory , how the runtime (it) know that this area is const or not , what kind of flag is this ?

[Vlykarye]

http://www.cplusplus.com/doc/tutorial%20%20/typecasting/

I would suggest reading the whole page that this site gives to you.

[Vlykarye]

Google search "how are constant variables stored in memory"

Check some of the links. Stack overflow is a good site to get information, because people can keep adding to the topic.

Constant memory is something implemented by the compiler.

[S6k9GNh0]

A good rule of thumb is to *never* use const_cast. To use it most likely means serious design flaws or incorrect use.

[Vlykarye]

^ true.

[clanmjc]

const_cast removes or adds the const and volitale qualifies to an object.

Your example strike86 isn't a good example of how it can be used because you are using string literal constant. Here is something that will compile.

class MyClass
{
    public:
     void Print() //notice this is non-const...
     {
         std::cout << "Inside Print" << std::endl;
     }
};

//void SomeFunction(const &MyClass obj)
//{
//     obj.Print();  //As is the compiler will complain, because obj is a const //object inside this function and the Print function is non-const
//}

//Using const_cast you can do this...
void SomeFunction(const &MyClass obj)
{
     const_cast<MyClass &>(obj.Print()); 
}

disclaimer: This example is not the end all be all, just shows a simple use case, whether this case makes any sense... if it helps understand the concept for just 1 person, good enough for me.

[andywestken]

I'm with computerquip and Vlykarye -- you should never, ever use const_cast<> !!

But I have been forced to use clanmjc's approach in legacy code, where the proper fix (e.g. make MyClass::Print const) would have created so much ripple in the rest of code base -- due to const laziness -- that we had to break the no-const_cast rule. But we did know the function we were calling could and should have been const in the first place!

[aquaz]

Basically using const_cast is just shooting yourself in the foot:

1)Constness in C++ have nothing to do with runtime: a const variable can be stored in a modifiable hardware location. It is just an information you give to the compiler to say "I promise i will never change this variable during runtime"

2) With this promise, the compiler can do a lot of optimisations and considers a const variable will be the same everywhere it appears.

3) So if you break this promise with const_cast, stange things could appear. Consider this piece of code:

int main()
{
const int i = 5;
const_cast<int&>(i) = 8;
cout << i;
}

In theory this must output 8 but in practice a lot of compilers (including gcc and MSVS) will output 5 because you promised "i" will not change so they can replace the i of cout << i by 5.

And now if I define this function:

void c(const int& i)
{
    cout << i;
}

and replace the last code by:

int main()
{
    const int i = 5;
    const_cast<int&>(i) = 8;
    c(i);
}

This time we get 8 because the real "i" will be output. The compiler cannot guess the value of "i" in function "c".

[aquaz]

Actually I can think of one valid use of const_cast mentionned by Scott Meyers in Effective C++ Third Edition(Chapter 1 item 3) to avoid ducplications of code for const methods and their non-const equivalent in classes.
details:
http://stackoverflow.com/questions/123758/how-do-i-remove-code-duplication-between-similar-const-and-non-const-member-func

[Peter87]

^ I was just going to mention this. It's the only good use of const_cast I have seen.

[clanmjc]

^ I use this technique everywhere.

That said, there are places in code where we have used const_cast and not because we made any promises, but because we had to use what the standard library gave us.

e.g. - We've used std::sets where the element type had state information that does not have anything to do with equivalence. std::set elements themselves are keys, therefore any iterator to a set is a const_iterator, const_cast has to be used to change the state information (they could have made this info mutable and maybe they should, but they didn't). That said, changing this info does not mean that they key itself needs to be rehashed, because like I said earlier it has nothing to do with equivalence.

[S6k9GNh0]

If you're using const_cast with stuff the standard library provides, I'm almost certain you're doing it wrong.

Also, I'm unsure of what you mean every iterator to an std::set must be a const_iterator.

EDIT: I *think* you mean an element that's set cannot be changed and instead, you must erase and then add a new element...?

[aquaz]

chanmjc => I met exactly the same problem and I think I resolved it by splitting the key into the key part and the value part into two separate class to use a map instead of a set.

But I agree this may be difficult if this class is used everywhere as this may involve a big refactoring.

[clanmjc]

computerquip said

Also, I'm unsure of what you mean every iterator to an std::set must be a const_iterator.

When you perform a find and get back an iterator to an element of a set, that iterator is a const_iterater, because the element the iterator points to is a key and should not be mutable. (at least in my STL implementation)

EDIT: I *think* you mean an element that's set cannot be changed and instead, you must erase and then add a new element...?

This is correct, if I want to change something that would change the sortdedness of the set, then I would first need to erase, then add. What I'm talking about though is in place modifications that do not effect sortdedness (and are transparent to everyone).

@aquaz - We have a custom container that we use for lockless threading and cannot split it (at least not easibly). Using const_cast in this scenario has no drawback really

To quote Scott Meyers for a second time in the same thread:

If portability is not a concern, you want to change the value of an element in a set or multiset, and your STL implementation will not let you get away with it, go ahead and do it. Just be sure not to change a key part of the element, i.e., a part of the element that could affect the sortedness of the container.

[aquaz]

Yes I guess there is no drawback...

Still I just remembered of the mutable keyword, maybe you could use it for the mutable part of the container?

[clanmjc]

Yes we thought about using mutable, but we wanted to ensure that later on when other developers are using said container, that they be forewarned by the compiler.