为何C++中带析构函数的类数组new时会额外占用8字节存储对象数？

先看你提供的代码：

#include <iostream>
class A {
    int t = -1;
public:
    ~A() { std::cout << "destructor" << std::endl; }
};

int main()
{
    A* a = new A[4];
    return 0;
}

在VS2022中观察到的数组指针前8字节存储元素个数（这里是4），是编译器为了处理数组销毁、动态类型等场景的必要设计，核心优势和必要性体现在以下几点：

• 保证非平凡析构函数的正确调用
  当类拥有自定义析构函数（比如你的类A），delete[]时需要明确知道要调用多少次析构函数。如果靠「总内存大小 / sizeof(A)」计算个数，会存在致命问题：比如内存分配时可能因为对齐要求或分配器自身的管理开销，实际分配的总大小大于n * sizeof(A)，这时候计算出来的个数会偏大，导致析构函数调用越界；反之如果有特殊的压缩存储场景，个数会偏小，导致部分对象未被正确销毁。直接存储元素个数可以100%保证析构次数准确。

• 兼容基类指针指向派生类数组的场景
  假设代码中有继承关系：

  class Base {
  public:
      virtual ~Base() {}
  };
  class Derived : public Base {
      int data;
  };
  Base* arr = new Derived[4];
  

  此时sizeof(Base)和sizeof(Derived)不相等，如果用总大小除以sizeof(Base)，得到的个数会是(4*sizeof(Derived))/sizeof(Base)，明显不等于实际的4个。而提前存储的元素个数可以让delete[] arr准确调用4次Derived的析构函数，避免内存泄漏或未定义行为。

• 速度与确定性的权衡
  读取预先存储的元素个数是O(1)的直接操作，而计算总大小除以类大小需要额外的除法运算，对于频繁创建销毁数组的场景，前者效率更高。同时，总内存大小的获取可能依赖分配器的内部实现，不同平台或分配器的总大小计算逻辑不一致，直接存储个数可以保证行为的确定性，避免依赖底层细节。

• 内存对齐的天然适配
  在64位系统中，8字节刚好是指针和整数的对齐要求，存储元素个数的区域本身不会破坏数组对象的内存对齐规则。如果不存储这个数值，反而可能需要额外的填充字节来满足对齐要求，最终并没有节省内存空间。

综上，这8字节的额外存储不是浪费，而是编译器为了保证数组操作的正确性、兼容性和效率所做的必要设计，无法简单用「总大小/类大小」的方式替代。

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