为何在Visual Studio中添加类专属operator delete会触发分配省略？

这确实是个挺有意思的编译器细节，咱来一步步拆解背后的逻辑~

一、为啥加了类专属operator delete就触发了分配省略？ #

核心逻辑绕不开C++标准的分配省略规则和Visual Studio优化器的“小心思”：

1. 先讲标准的大前提
   C++14之后就允许编译器省略掉“new完立刻delete”这种无意义的分配/释放操作，但有个关键前提：编译器得确定这整串操作没有可观察的副作用——简单说就是，执行或不执行这堆new/delete，程序的对外表现完全一样。

2. VS优化器的“区别对待”

   • 对于全局默认的operator delete：VS的优化器默认会“谨慎行事”——它不确定全局delete有没有隐藏的副作用（比如调试模式下的内存跟踪、全局分配器的统计逻辑之类的），哪怕你看起来只是new完马上删，编译器也不敢赌这操作完全没痕迹，所以老老实实地生成了分配和释放的代码。
   • 对于你写的那个constexpr类专属operator delete：因为它是constexpr函数，编译器能在编译期把它的逻辑扒得明明白白——你的delete函数就是判断指针非空后调用全局delete，而整个new A; delete A的操作下来，除了折腾了一下内存，对程序的可见行为半毛钱影响都没有（最终x还是被赋值为0）。优化器一眼就看出来：这堆操作完全是白费功夫，直接把整个初始化逻辑都砍了就行——连动态初始化函数都不需要，直接把x在编译期就设为0，用静态初始化搞定。

二、还有哪些办法能触发VS的分配省略？ #

除了你发现的这个技巧，还有这些常见的路子：

1. 让分配/释放操作完全“透明无副作用”
   比如给类写个空的operator new和operator delete（只要符合标准规则就行）：

struct A {
    static void* operator new(size_t) { return nullptr; }
    static void operator delete(void*) {}
};
bool x = (delete new A, 0);

这种情况编译器绝对会省略，因为分配和释放啥实际事都没干，完全是无用功。

2. 用上C++20的constexpr new/delete
   如果你的编译器支持C++20，把new和delete都改成constexpr的，编译器能在编译期直接消解整个操作——毕竟constexpr要求函数在编译期就能被求值，编译器很容易判断这操作有没有副作用。

3. 给编译器明确的“无副作用”提示
   比如用VS支持的__declspec(noalias)属性标记释放函数，不过更靠谱的还是让函数本身的逻辑足够简单，比如写一个完全没有额外操作的delete函数，让编译器能自动看出来这操作不会影响程序的可见行为。

4. 拉高优化等级触发自动优化
   当你把VS的优化等级开到O2或者更高时，编译器会更积极地做这类优化——哪怕是用全局默认的new/delete，只要编译器能确定操作无副作用，也可能会触发分配省略。不过这种情况就比较依赖编译器的自动分析，不如前面几种方法稳定。

最后要提醒一句：分配省略是编译器的可选优化，不同编译器（比如GCC、Clang）的触发条件可能和VS不一样，所以千万别把它当成程序的核心逻辑依赖，只是用来优化代码的小技巧就好~

备注：内容来源于stack exchange，提问作者Fedor