去除*this的const限定是否会引发未定义行为？附代码示例

这个问题问得很到位——很多开发者在const成员函数里用const_cast去掉*this的const性时，都会纠结会不会踩未定义行为（UB）的坑。咱们结合你的代码和C++标准来分析：

先看你的测试代码的情况 #

你的代码片段如下：

class A { 
public: 
    A(const int x) : x_(x) {} 
    void set_x(int x) { x_ = x; } 
    void set_x2(const int x) const { 
        const_cast<A&>(*this).set_x(x); 
    } 
    int x_; 
}; 

int main() { 
    A a(10); 
    a.set_x2(100); 
}

在这个场景下，完全不会触发未定义行为。原因很简单：

• main里的对象a是一个非const的A对象，它本身是允许被修改的。
• set_x2是const成员函数，所以函数里的this是const A*类型，*this是const A&；但用const_cast<A&>(*this)去掉const限定后，本质上是把引用转回了原始对象的真实类型（非const的A&），后续调用set_x修改成员变量，只是在操作一个原本就可修改的对象，完全符合C++标准的规定。

什么时候会触发未定义行为？ #

只有当原始对象本身是const的时候，用const_cast去掉*this的const性再修改，才会导致UB。比如把main改成这样：

int main() { 
    const A a(10); 
    a.set_x2(100); // 这里会触发未定义行为！
}

因为const对象的成员变量在语义上是不可修改的，编译器可能会将其放在只读内存区域，或者做一些激进的优化（比如把成员变量的值直接硬编码到代码里），强制修改会导致程序崩溃、输出异常结果等不可预测的行为。

一些额外的建议 #

虽然你的代码在当前场景下没问题，但这种写法其实打破了const成员函数的语义承诺——const成员函数本来是向调用者保证“我不会修改对象状态”的，你这么做相当于偷偷修改了对象，可能会让其他开发者感到困惑。

如果你确实需要让类似my_iterator的const迭代器能修改指向的数据，建议：

• 确保这个迭代器指向的对象本身一定是非const的，避免出现上述触发UB的场景；
• 考虑重新设计接口，比如将修改操作放在非const成员函数中，或者明确区分迭代器的职责（比如像标准库那样，用iterator和const_iterator分别处理可修改和不可修改的场景）。

内容的提问来源于stack exchange，提问作者R zu