编程随想：可以delete this吗？

在C++中能不能delete this，去问AI，它能给你一个基本上算是标准答案的回答。面面俱到，滴水不漏。

在C++中，从技术上讲，你可以在类的成员函数中调用 delete this。然而，强烈不推荐这样做，因为它非常危险，并且会带来很多潜在的问题。……

看起来是不太好的，至少是不推荐。
但是如果你改一个问法，去问可不可以「对堆上new出来的非模态对话框在PostNcDestroy中做delete this操作」，那它又会改口了。

在MFC中，当你在堆上new了一个窗口类，并且它是一个非模态对话框，那么在PostNcDestroy中调用delete this是完全安全且合理的。这是一种标准的MFC编程模式，专门用于解决你所描述的生命周期管理问题。……

所以，事情都得分场合来看。有些情况下「坏事」也可以变成「好事」，至少会是合理的。反过来也一样。大多数情况下，对具有某个「标签」的事物并不应该有唯一的判断结论，因为它可能还有别的标签（不知道3D人士看不看得懂）。

---

上述资讯，其实算是C++开发的基本功。MFC开发如果入了门，也不应该有此疑惑。不过呢，世间的事情很多都比较复杂，并不像示例或教科书上那样简单、清晰、明了。夹杂了别的东西之后，情况就又发生了变化。

最近在查一个问题，就遇到了一个案例。
有个小弟，在PostNcDestroy里面，去上了一把锁。std::mutex，成员变量，用std::unique_lock辅助管理。
然后程序就Crash了。调试起来倒也容易，因为这个虽然看起来跟多线程有关，但也并不是真正的多线程问题，还是很容易复现的。

我也不多啰嗦。到了这把年纪，很多抖擞精神去查的问题，结论出来以后都失望无比，最后写都懒得去写，何况世上还有AI。有经验的程序员应该一眼就看出问题了：std::unique_lock在PostNcDestroy函数退出时，才会把自己管理的std::mutex给解锁，但那个时候这把锁的主人已经把自己给毙了。这就相当于访问了无主内存。

所以，「自毙」这种事情，虽然不是不可以，但后事还是要先安排好。

---

图片由Google Gemini生成

比如，「禁诉令」这件事就做得很好。否则法院可能哪天就得直接关门了。