7 Answers
7

const_cast is safe only if you're casting a variable that was originally non-const. For example, if you have a function that takes a parameter of a const char *, and you pass in a modifiable char *, it's safe to const_cast that parameter back to a char * and modify it. However, if the original variable was in fact const, then using const_cast will result in undefined behavior.

It's not true. C++ standard. §7.1.​5.1/4 says Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behaviorAny attempt! There are no words about original variable.
–
Alexey MalistovNov 8 '10 at 15:12

8

@Alexey: The original variable is about what is pointed to or referred to. You can take a const reference to a non-const object, and therefore, casting it to a writable reference is well-defined behaviour as the referred-to object is not actually const.
–
PuppyNov 9 '10 at 16:53

1

Stanard says any attempt! There is no information about initial definition.
–
Alexey MalistovNov 12 '10 at 10:29

21

@Alexey Malistov: No. An "object" refers to the actual region of storage occupied in memory (§1.7). Taking a const reference to a non-const object does not make the object const. Only in the case of a const reference parameter (not a const pointer parameter) is the compiler allowed to silently make a copy (§5.2.2/5); this is not the case here.
–
Adam RosenfieldNov 12 '10 at 16:02

1

Are literals the only data that is originally declared as const?
–
TahlilJun 25 '14 at 4:37

Grrrreaat answer, combine this with this answer and you get the whole picture.
–
boboboboSep 4 '11 at 14:36

hmm. regarding the second statement in your answer, may i ask you how is there a "const"ness for an object which was not explicitly declared as const in the first place?.
–
hAcKnRoCkApr 16 '12 at 11:40

There are lots of ways to make a non-const object be const, @Iam. For example, pass the object as a const-reference parameter. Or assign it to a pointer-to-const. Or use const_cast. Or call a const method on it.
–
Rob KennedyApr 16 '12 at 13:15

@RobKennedy: Thanks a lot. I get it. const is a very bad naming convention though :)
–
hAcKnRoCkApr 19 '12 at 14:50

I can think of two situations where const_cast is useful (there may be other valid cases).

One is when you have a const instance, reference, or pointer, and you want to pass a pointer or reference to an API that is not const-correct, but that you're CERTAIN won't modify the object. You can const_cast the pointer and pass it to the API, trusting that it won't really change anything. For example:

The other is if you're using an older compiler that doesn't implement 'mutable', and you want to create a class that is logically const but not bitwise const. You can const_cast 'this' within a const method and modify members of your class.

We first add const to the type this points to, then we call the const version of getT, and then we remove const from the return type, which is valid since t must be non-const (otherwise, the non-const version of getT couldn't have been called). This can be very useful if you got a large function body and you want to avoid redundant code.

I would rather use static cast for the adding constness: static_cast<const sample*>(this). When I'm reading const_cast it means that the code is doing something potentially dangerous, so i try to avoid it's use when possible.
–
mfazekasJan 9 '09 at 7:08

right, the first can be static_cast, or even be implicit_cast (of boost). i'll fix it using static cast. thanks
–
Johannes Schaub - litbJan 9 '09 at 11:56

1

I go back and forth on whether const_cast or static_cast is better. const_cast can only do what you want: change the cv-qualifiers. static_cast can 'silently' perform other operations that you don't intend. However, the first cast is entirely safe, and static_cast tends to be safer than const_cast. I think this is a situation where the const_cast communicates your intent better, but the static_cast communicates the safety of your actions better.
–
David StoneFeb 21 '13 at 17:21

The long answer is that if you know enough to use it, then it should be safe.

When you're casting, what you are essentially saying is, "I know something the compiler doesn't know." In the case of const_cast, what you are saying is, "Even though this method takes in a non-const reference or pointer, I know that it won't change the parameter I pass it."

So if you do actually know what you are claiming to know in using the cast, then it's fine to use it.

What? If you have immutable (const) objects, you can trivially share them amongst threads. The instant that a piece of your code casts away const-ness, you lose all of your thread safety! Why am I down-modded for this? sigh
–
Matt CruikshankDec 10 '08 at 22:53

2

Const is certainly a useful tool in making code thread-safe, but it gives no guarantees (except in the case of compile-time constants). Two examples: a const object may have mutable members, and having a const pointer to an object says nothing about whether the object itself could be changing.
–
James HopkinDec 11 '08 at 9:29

+1 for bringing the issue up, though :-)
–
James HopkinDec 11 '08 at 9:32

I think this is a good answer because I didn't think about the compiler optimizer's feelings of trust and security in your use of the word const. const is trust. const_cast is breaking that trust :(
–
boboboboSep 4 '11 at 14:35

This explains the use of the const_cast operator but does not clearly answer the question.
–
Mag RoaderJul 20 '12 at 15:12

If the compiler to place in the read-only memory, an error to access this memory and the OS will complete the application.
–
Mr.AngelAug 9 '12 at 12:30

Accordingly, it is safe to be used only to constants, which were created during the program, because these constants are always placed in the memory allowed for the recording (read-write).
–
Mr.AngelAug 9 '12 at 12:39