Is it safe to remove const via const_cast and invoke a non-const function that does not modify the resulting object?

Question

I know that casting away const-ness should be done with care, and any attempt to remove const-ness from an initially const object foll

Answer 1

Undefined behavior with respect to const_cast is defined by the C++11 standard's §3.8/9 (§3.8 is “Object lifetime”):

” Creating a new object at the storage location that a const object with static, thread, or automatic storage duration occupies or, at the storage location that such a const object used to occupy before its lifetime ended results in undefined behavior.

and §7.1.6.1/4 (§7.1.6.1 is “The cv-qualifiers”)

” 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 behavior.

In other words, you get UB if you modify an originally const object, and otherwise ¹not.

The const_cast itself doesn't introduce UB.

---

There is additionally a non-normative note at §5.2.11/7 that “depending on the type” a write through the pointer or reference obtained from a const_cast, may have undefined behavior.

This non-normative note is so wooly that it has its own non-normative footnote, that explains that “const_cast is not limited to conversions that cast away a const-qualifier.”.

However, still with that clarification I fail to think of any case where the write could be well-defined or not depending on the type, i.e., I fail to make sense of this note. Two other answers here focus on the word “write” in this note, and that's necessary to get into UB-land via §3.8/9, yes. The to me rather fishy aspect is the “depending on the type”, which appears to be the significant part of that note.

---

^{1) Except insofar as UB-rules about other non-const_cast-related things get into play, e.g. nulling a pointer that's later dereferenced in a context other than as typeid-expression.}

Answer 2

This particular example happens to be safe (have well defined behavior) because there is no write to an object which is declared const.

Answer 3

We have this in [dcl.type.cv]:

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 behavior.

And there is a note (non-normative) in [expr.const.cast] which states:

[Note: Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data member resulting from a const_cast that casts away a const-qualifier may produce undefined behavior (7.1.6.1). —end note ]

An attempt to modify an object or a write operation after a const_cast [may] result in undefined behavior. Here, we have no write operation.