5

In another question I ran across this code:

Real StatData::mean(Real trim) const { // trim, pun not intended const_cast<StatData&>(*this).items.sort(); // trim }

cppreference also has an example on their page:

struct type { type() :i(3) {} void m1(int v) const { // this->i = v; // compile error: this is a pointer to const const_cast<type*>(this)->i = v; // OK } int i; };

Aside from the obvious question of why this would ever be practical, is it unsafe? Does it matter of the object created is const or not and more importantly, is the this pointer safe from undefined behavior because it's only marked const for that one function?

Improve this question
2
  • Depends what items is and what sort does... Commented Aug 15, 2014 at 23:55
  • 1
    const StatData x; x.mean(Real()); >>> ???? >>> NOT PROFIT Commented Aug 15, 2014 at 23:58

2 Answers 2

Reset to default
9

Does it matter of the object created is const or not

Yes. If the object was created non-const, then no matter what you do the const_cast will be safe. Just a bad idea (because in general you don't know what the object was created non-const).

the this pointer safe from undefined behavior because it's only marked const for that one function?

That's the wrong question really, but the point is that until you try to modify a const object you're safe. That means the const_cast itself is perfectly legal and well-defined, but if items.sort() modifies stuff (and we have to assume it does) then that operation results in UB.

Finally, although you've tried to gloss over this point in your question, the practicality of this is actually fundamental to the scenario: it's remarkably difficult to guarantee, even in this seemingly specific case, that the code is safe. So, don't do it. Despite your attempts at abstracting it away for the purposes of this question, I can't stress that enough.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

6

const_cast itself is never undefined behavior. It could be ill-formed, i.e fail to compile. But if it is well-formed (i.e. compilable) then it cannot produce undefined behavior by itself.

Undefined behavior might be triggered by what you do later with the [non-constant] access path you obtained with the help of const_cast. But it is a completely different story, not directly related to const_cast.

The code samples you posted so far are insufficient to tell whether they exhibit undefined behavior or not. It all depends on the external factors: on whether the object being modified is really declared as const or not. An attempt to modify const object triggers undefined behavior.

For example, for the type class above, this code triggers UB

const type t; t.m1(42); // <- undefined behavior

while this one does not

type t; t.m1(42); assert(t.i == 42);
Improve this answer

1 Comment

Technically, I think const_cast itself may be undefined behaviour in one extremely rare corner case: in an expression where the order of evaluation is unspecified, the operand of const_cast may have been a valid pointer when that was evaluated, but become invalidated by the time the const_cast gets evaluated. (That's nit-picking, I know.)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.