非new表达式构造的对象执行delete是否可行？含特定代码场景问询

好问题！先给你一个直白的结论：在大多数主流编译器（GCC、Clang、MSVC）的默认生产环境下，这段代码实际运行起来大概率是正常的，但背后藏着规范风险和潜在的坑，我给你拆解清楚：

先明确规范层面的硬限制 #

根据C++标准的定义，delete表达式的操作数必须是以下两种情况之一：

1. 之前由非placement版本的new表达式返回的指针；
2. 空指针。

你代码里的p是直接通过operator new分配的内存，再用placement new构造对象，这种情况下调用delete p属于标准明确标记的未定义行为——编译器可以自由处理，不保证任何结果。

为什么实际工程里可能"看起来可行"？ #

主流编译器的delete实现，针对非数组类型的指针，本质上会做两件事：

1. 调用指针指向对象的析构函数；
2. 调用对应的operator delete释放内存。

你的代码刚好凑齐了这两步的匹配条件：

• 对象是通过placement new正常构造的，析构函数调用是合法的；
• 你假设new没被替换，也就是operator new用的是全局默认版本，而delete默认会调用全局的operator delete，和分配时的函数配对，内存释放不会出问题。

但绝对不能依赖这种"可行"，这些风险要注意 #

• 类专属内存管理的冲突：如果T类重载了自己的operator delete（比如用了自定义内存池），那delete p会调用这个类专属版本，而你是用全局operator new分配的内存，两者逻辑不匹配，直接会导致内存泄漏或者崩溃。
• 编译器严格检查的拦截：在一些编译器的Debug模式下（比如MSVC的Debug CRT），会对delete的指针做合法性校验，检查它是否是由new表达式返回的指针，这时候会直接触发断言报错。
• 可移植性为0：换个小众编译器、开启严格编译选项（比如-fstrict-aliasing或者-Wall -Werror），或者未来编译器版本更新，都可能让这段代码突然失效。

标准合规的正确写法 #

如果要手动管理内存+placement new，正确的流程应该是手动调用析构函数，再用operator delete配对释放内存，完全符合标准，没有任何风险：

auto p = static_cast<T*>(operator new(sizeof(T)));
new(p) T{};
// 这里正常使用对象p
p->~T(); // 手动调用析构函数
operator delete(p); // 用operator delete释放内存

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