C++中destroying delete缺失的替代方案及合法性探讨

背景 #

C20引入的「destroying delete」允许自定义operator delete重载，在对象仍存活时执行销毁逻辑（比如委托给对象自带的分配器）。但该特性既不支持协程，也无法在C20之前的版本中使用，因此有人提出了一种替代思路：

• 用MaybeUninit<T>存储所有成员，避免编译器自动调用成员析构函数：

  template<class T>
  class MaybeUninit {
      alignas(T) char _storage[sizeof(T)];
  };
  

• 将目标类Foo的析构函数定义为空：

  class Foo {
  public:
      ~Foo() {}
  
      // ... 其他成员
  };
  

• 最后在operator delete中，将void*转换为Foo*，手动执行成员的析构逻辑。

核心问题：这种做法属于未定义行为吗？ #

是的，这绝对是未定义行为（UB）。

C++标准规定：对象的生命周期在析构函数开始执行时就已结束——哪怕析构函数是空的。当编译器调用完~Foo()后，会认为Foo对象已经销毁，此时任何将void*转换回Foo*并访问对象的操作，都违反了对象生命周期的规则。编译器可能会对此做极端优化：比如直接删除你在operator delete中的手动析构代码，或者因为认为内存已失效而导致内存访问错误。

如何挽救这个技巧？ #

可以通过以下几种合法的方式实现类似destroying delete的效果：

• 禁止编译器自动调用析构函数
  把Foo的析构函数设为私有，提供自定义的销毁函数（比如static void destroy(Foo* ptr)）。在这个销毁函数里，先执行成员的手动析构逻辑，再调用operator delete释放内存。这种方式需要确保所有销毁操作都走这个自定义函数，外部不能直接调用delete。

• 分离控制块与资源存储
  在分配Foo对象的内存时，额外分配一个"控制块"（存储分配器、析构所需的元信息等），并让Foo对象持有指向控制块的指针。当operator delete被调用时，先通过指针找到控制块，再利用控制块里的信息手动析构成员。此时Foo对象的生命周期虽然结束，但控制块的生命周期仍有效（因为它和Foo在同一块内存中，尚未被释放），访问控制块是合法的。

• 谨慎使用std::launder（C++17及以上）
  如果你必须在operator delete中访问已销毁的Foo对象，可以用std::launder告诉编译器：该指针指向的内存中仍然有可访问的对象（前提是你手动管理的MaybeUninit成员确实还处于有效状态，且内存未被复用）。不过这种方式高度依赖编译器实现，容易出现难以调试的问题，不推荐作为通用方案。

• C++20之前的手动销毁流程
  直接绕过delete的自动析构逻辑：先调用自定义的析构函数（手动处理MaybeUninit里的成员），再调用operator delete(ptr)释放内存。比如：

  void destroy_and_deallocate(Foo* ptr) {
      // 手动析构MaybeUninit中的成员
      auto& member = *reinterpret_cast<T*>(&ptr->_member_storage);
      member.~T();
      // 释放内存
      operator delete(ptr);
  }
  

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