这家伙：
virtual phTreeClass* GetTreeClass() const { return (phTreeClass*)m_entity_class; }
调用时，即使在完全重新编译之后，也会因访问冲突而导致程序崩溃。所有成员函数和虚拟成员函数都有正确的内存地址（我在调试模式下将鼠标悬停在方法上），但此函数的内存地址不正确：0xfffffffc。
一切看起来还不错：'this'指针，一切正常，直到这个函数调用。这个功能也很老了，我很长时间没有改变它。在一些工作之后突然出现问题，我全力以赴地看看它在做什么，没有任何成功。
所以我删除了虚拟，编译，它工作正常。我添加虚拟，编译，它仍然可以正常工作！我基本上没有改变任何东西，并且记得我之前做过完整的重新编译，但当时仍然有错误。
我无法重现这个问题。但现在又回来了。我什么都没改变。删除虚拟修复了问题。
答案 0 :(得分：2)
除非你非常确定自己在做什么，否则不要使用具有多态类型的C风格的演员表。压倒性的可能性是你把它投射到一个它不是的类型。如果你的指针没有隐式转换（因为它们转换为基类，这是安全的）那么你做错了。
答案 1 :(得分：0)
编译器和链接器是由人类编写的软件，与其他任何软件一样，因此本质上不会没有错误。
我们偶尔会遇到这样莫名其妙的问题和修复。这里有一个神话，在修复构建后删除ncb文件..
答案 2 :(得分：0)
鉴于重新编译最初解决了问题，请先尝试完全清理并重建。
如果失败了，那么即使你的this指针看起来对你来说很有可能，它实际上也被删除/解构并指向垃圾内存，它恰好看起来像真正的对象。之前。如果您正在使用gdb进行调试，则对象指针的第一个单词将是vtable。如果你在那个位置进行x/16xw <addr>（例如）内存转储，gdb将告诉你哪个对象的vtable存在于那里。如果它是最父类型，则对象肯定不见了。
或者，如果每次在类析构函数中使用this == known_addr的条件放置断点时，this指针是相同的。