关于if to put null check before delete 有几个问题。现在，我仍然在许多生产代码中看到了这种做法，我不相信所有这些程序员都不知道delete 0; 是安全的这一事实。
所以，我想知道是否值得假设delete/free 之前的空检查会通过保存函数调用来提供性能优化？
if(0 != p)
delete p;
【问题讨论】：
if (0 != p)：个人喜好，但我发现使用中的一种更丑陋的构造，通常是强制使用（在项目编码标准中）。
标签： c++ optimization null delete-operator
没有。 delete 不是一个函数，但根据类型的不同，它后面可能有一个 operator delete 调用。
您最多可以保存第二个与0 的比较。这都是过早的优化：这些都不会成为您的瓶颈，而且您正在编写冗余代码。
只写：
delete ptr;
【讨论】：
我不相信所有这些 程序员不知道这个事实 删除0；是安全的。
嗯，他们是。差不多就是这样。事实上，null 上的 delete 或 free 是完全安全的。如果他们没有意识到这一点，那么他们就不会浪费时间检查它。
所以，我想知道这不值得 假设之前的空检查 delete/free 将提供一个 通过节省性能优化 函数调用？
你在做一个假设……因为什么，你不想相信那些人是错的？对不起，伙计——他们错了，就是这样。你没有证据或合理的理由相信进行null 检查有这样的好处。
或者编写该代码的人是这么认为的。毕竟，即使您可以以这种方式消除函数调用，这里的函数调用成本也是微乎其微的，如果它没有内联的话，它很可能是内联的，而且程序员的时间成本更高写支票，它已经为你写好了。我宁愿对正确性过分热心，也不愿像这样过早地优化——你真的是在帮别人一个忙，暗示它可能是一种优化吗？
【讨论】：
现在，我仍然在许多生产代码中看到了这样的做法，我不相信所有这些程序员都不知道删除 0 的事实；是安全的。
很久很久以前，无法保证delete（和free）不会对空指针无害地执行任何操作。相反，他们用一些编译器/一些机器炸毁了。因此，这种做法的起源。
使这种做法保持活力的是货物崇拜编程和小头脑心态的结合（“愚蠢的一致性是小头脑的妖精。”）货物崇拜程序员使用剪切和粘贴，所以当他们看到一些广泛 -使用他们复制它的语法。在这种情况下，由于某些代码会执行空指针检查，因此狂热的程序员会认为这是执行此操作的方法。
心胸狭隘的心态决定了只有一种方法可以做到这一点。因为一些没人想接触的陈旧旧代码使用这种空指针检查，所以所有代码都必须以这种方式释放动态分配的内存。我见过多个项目的编码标准要求这种行为（这些编码标准本身是由货物崇拜技术创建的）。
【讨论】：
free）中明确有保证，我似乎记得在 K&R C（第一版——但我的记忆力并不总是那么好，所以我可能错了）。
free 应该如何处理空指针。很多系统都炸了。虽然第一个 C 标准确实在 1990 年问世，但当供应商决定让他们的编译器兼容时，情况就不同了。在标准发布后的相当长一段时间内，程序继续以free(0) 爆发。但据我所知，不是在这个千年。