C++标准是否允许或禁止在对象方法运行期间删除该对象？

嘿，我来聊聊你代码库里这种「对象在成员方法执行期间被删除」的场景——尤其是自删除对象的写法，这在资源管理类里其实挺常见，但细节没拿捏好很容易踩坑。先把你提到的典型示例代码贴出来：

class SomeResource {
public:
    SomeResource() = default;
    void Close() {
        // 删除前读取状态
        const uint64_t id = id_;
        delete this;
        // 使用之前读取的内容
        std::cout << "Closed resource with ID " << id;
    }
    // ... 其他成员定义
private:
    uint64_t id_; // 示例成员变量
};

这种写法的安全性核心 #

你强调的「方法保证在执行delete操作时已停止使用对象的成员」是关键中的关键！这个示例之所以安全，完全是因为在delete this之前，已经把需要后续使用的对象成员id_拷贝到了栈上的局部变量id里。

一旦delete this执行，当前对象占用的内存就被释放了，此时this指针变成了野指针，再访问对象的任何成员（比如直接用id_）、调用其他成员方法，都是未定义行为——程序可能崩溃、输出乱码，甚至看起来正常但埋下隐患。而局部变量id存在于栈上，和对象内存无关，所以delete之后用它完全没问题。

必须避开的几个坑 #

• 绝对不能在delete this之后访问对象的任何成员或调用成员方法，哪怕那个方法看起来只是个简单的getter也不行。
• 别在构造函数里玩delete this——对象还没完全构造完成，这么做会直接破坏对象的初始化流程，大概率触发崩溃。
• 如果对象是用new[]分配的，一定要用delete[] this来匹配，分配和释放方式不匹配也是未定义行为。
• 线程环境下要格外小心：如果有其他线程同时访问这个对象，哪怕你在Close里删了自己，其他线程可能还在读写对象成员，这会导致竞态条件。这种自删除模式更适合单线程场景，或者必须做好同步，确保调用Close后没有其他线程再碰这个对象。

实践替代方案 #

如果业务允许，其实更推荐用智能指针（比如std::unique_ptr）来管理对象生命周期，让智能指针自动处理销毁逻辑，能避免手动delete this的风险。但如果你的业务逻辑确实需要对象自己触发销毁（比如资源用完后自我清理），那只要严格遵守「先拷贝需要的成员到局部变量，再执行delete」的规则，这种写法是完全可行的。

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