已delete的new创建C++对象仍可调用成员函数？原因及防范

嘿，这个问题问得特别戳中C++内存管理的一个“灰色地带”——很多开发者刚接触时都会被这种“看似正常”的现象搞懵。咱们一步步拆解清楚：

一、当前环境下不崩溃的核心原因 #

首先得搞懂C++成员函数的调用逻辑：

• 对于非虚成员函数，编译器在编译阶段就已经把调用绑定到了具体的函数代码上。cat->meow()本质上会被转换成Cat::meow(cat)——这里的cat只是作为this指针传递给函数。
• 函数本身的代码是存在程序的代码段里的，和堆上的对象内存完全分开。只要meow()里没有访问对象的成员变量，那它根本不需要读写堆上那块已被释放的内存，自然能正常执行。
• 再加上你用的g++ 5.4搭配Ubuntu 16.04的glibc内存分配器：delete堆内存后，系统不会立刻把内存还给操作系统，只是把这块内存标记为“空闲”。只要还没有其他分配操作覆盖这块内存，进程依然能访问它，不会触发段错误。

举个例子，如果你的meow()是这样的：

void Cat::meow() {
    cout << "Meow!" << endl;
}

它完全没碰对象的任何成员数据，哪怕this指针指向的内存已经被释放，函数照样能跑——因为它根本不需要用到那块内存的内容。

二、为什么其他环境下会崩溃？ #

这种“不崩溃”只是特定环境下的巧合，属于C++标准里的未定义行为，换个环境就可能出问题：

• 有些内存分配器在delete后会立刻给内存填充“poison value”（比如0xCC），这时如果函数里不小心访问了成员变量，就会触发错误。
• 要是开启了内存检测工具（比如ASAN），哪怕只是传递了指向已释放内存的this指针，工具也会立刻报错，帮你揪出问题。
• 不同的编译器优化策略也可能改变这个行为——比如编译器可能把成员函数内联，或者做一些内存相关的优化，导致访问已释放内存直接崩溃。

三、必须采取的防范措施 #

这种未定义行为绝对不能依赖，必须从根源上避免：

• 严格禁止访问已释放的对象：哪怕当前没崩溃，这也是严重的bug——今天没事，明天改个成员变量、换个编译器，或者系统内存紧张时，崩溃就会找上门。
• 用智能指针替代裸指针：比如std::unique_ptr<Cat>或std::shared_ptr，它们会自动管理内存，超出作用域就自动释放，从根本上杜绝手动delete后误操作的可能。
• 启用内存检测工具：开发时加上-fsanitize=address编译选项（命令改成g++ cat.cpp -pedantic -Wall -fsanitize=address -o cat），ASAN会立刻检测到对已释放内存的访问，帮你提前发现这类隐藏问题。
• 可选：给类添加有效性检查：可以在类里加一个bool is_valid成员，构造时设为true，析构时设为false，在成员函数开头检查这个标志——不过这只是辅助手段，不能替代规范的内存管理。

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