delete操作中多态对象大小的推导机制是怎样的？

首先明确：你看到的两种说法都不是全错，只是分别描述了C++语言层实现、堆实现两个不同层面的局部规则，两者并不矛盾，只是之前的理解把两个层面的逻辑混在一起了。

两种说法对应的实际运行规则 #

1. 「虚析构函数提供对象大小信息」是C++语言层的要求 #

这个描述对应的是编译器在生成delete逻辑时的行为，和堆本身的能力无关：

• 当基类定义了虚析构函数时，编译器遇到通过基类指针执行delete的代码，会生成通过虚表动态派发的逻辑：先从对象头的虚表指针找到对象真实类型（也就是示例中的B）的析构函数，先执行派生类的析构逻辑清理派生类成员持有的资源，再逐层执行基类析构；析构流程结束后，编译器会自动把真实类型的大小（sizeof(B)）、对象的真实起始地址传给底层堆释放函数，保证内存回收的参数正确。
• 如果基类没有虚析构，编译器在编译阶段就只会按照静态类型（也就是A）生成逻辑：只会调用A的析构函数，传给堆释放函数的大小也是sizeof(A)，不会感知到派生类的存在。之前理解的「拿不到B的大小就无法释放int b的内存」，是只看编译器传参逻辑得出的结论，但这个结论没考虑堆本身的实现。

2. 「堆可以自动推导对象大小」是主流用户态堆的内置能力 #

这个描述和C++多态没有任何关系，是堆分配器本身的设计：

• 所有通用操作系统的默认堆实现（比如glibc的ptmalloc、Windows的NT堆），在你调用malloc/operator new申请内存时，都会在返回给用户的内存块附近（通常是用户可用地址的头部预留空间，或者全局的堆管理哈希表中）存储这个内存块的元数据：包括块的总大小、是否在使用、前后块的指针等信息。
• 当你调用free/operator delete释放内存时，根本不需要传入块大小，分配器只需要拿到你传入的内存地址，就能直接查询到当初分配这个块时记录的真实总大小，直接把整块内存标记为可复用。
• 这也是很多人跑示例代码会发现「程序没崩溃、内存也没漏」的原因：单公有继承、无虚基类的场景下，基类子对象位于派生类对象的起始位置，A* p的值和new B返回的原始地址完全相同。哪怕编译器因为没有虚析构只传了sizeof(A)的大小参数，很多堆实现的释放逻辑根本不会用到编译器传入的大小参数，直接拿地址查元数据就能拿到当初分配的sizeof(B)的总大小，把包括int b在内的整块内存全部回收。

为什么没有虚析构的delete仍然是未定义行为 #

哪怕测试中发现示例代码能正常跑完、内存也确实全部释放了，这种写法仍然是标准规定的未定义行为，核心原因有三个：

• 第一，析构逻辑不会正确执行：没有虚析构时派生类的析构函数永远不会被调用，如果B有需要手动释放的资源（比如堆内存、文件句柄、锁），这些资源会直接泄漏，和对象本身的内存是否被回收无关。
• 第二，指针地址不一定匹配：如果是多继承、虚继承的场景，基类指针在隐式转换时会加上固定偏移，指向基类子对象的位置，这时候你传给delete的地址根本不是当初new返回的原始堆地址，堆分配器查元数据会拿到完全错误的块信息，直接触发崩溃或者堆结构破坏。
• 第三，实现不保证通用：C++标准没有对堆的实现做任何强制要求，部分嵌入式场景的极简堆实现甚至要求释放时手动传入块大小，这种场景下没有虚析构必然会出现内存回收错误。

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