重载C++类的new/delete运算符返回new char[]是否存在危害？

问题场景 #

在某项目的多数类中发现大量重载了类的new、new[]、delete、delete[]运算符的代码，具体实现如下：

void* MyObject::operator new ( size_t  size )
{
    return ( size == 0 ? NULL : new char[size] ) ;
}

void* MyObject::operator new[] ( size_t  size )
{
    return ( size == 0 ? NULL : new char[size] ) ;
}

void MyObject::operator delete( void *p )
{
    char* l_tmp = (char*)p;
    delete[] l_tmp;
}

void MyObject::operator delete[]( void *p )
{
    char* l_tmp = (char*)p;
    delete[] l_tmp;
}

本文将分析该实现是否存在内存、速度或稳定性方面的危害，以及其设计合理性。

一、稳定性与内存风险 #

• 分配释放不匹配的隐患：C++标准明确要求，new分配的内存必须用delete释放，new[]分配的必须用delete[]释放。当前实现中，单个对象的operator new用new char[]分配内存，却在operator delete中用delete[]释放——虽然char是平凡类型，两种释放方式行为一致，但如果后续类添加了非平凡析构函数，或者子类继承后修改了内存分配逻辑，会直接导致析构函数未被调用，引发内存泄漏、资源泄漏甚至程序崩溃。
• 零大小分配的兼容性问题：C++标准规定，size为0时operator new可以返回非空指针（只要后续delete能安全处理），但这里返回NULL。若代码依赖标准行为（比如对零大小分配的指针执行delete），跨编译器或标准版本时可能触发未定义行为。
• 异常处理的隐性问题：标准operator new分配失败时会抛出std::bad_alloc（或返回空，取决于C++版本），当前实现直接调用new char[size]，行为和标准一致，但如果项目预期分配失败返回空而非抛出异常，会导致逻辑错误。

二、速度层面的影响 #

这个实现只是对全局new[]和delete[]做了一层无意义的包装，没有任何内存池、缓存等优化，反而多了一层函数调用开销。如果项目中大量创建这些类的对象，频繁的函数调用会累积出可感知的性能损耗。

三、设计合理性分析 #

这种实现几乎没有任何合理的设计价值：

• 若目的是统一内存管理，通常会自定义内存池、添加内存跟踪逻辑，而非简单转发全局分配器。
• 若目的是处理零大小分配，标准分配器已经能妥善处理，返回NULL的方式不符合现代C++最佳实践。
• 若目的是替换默认分配逻辑，该实现完全没有达到预期效果，只是冗余且危险的重复包装。

唯一的可能性是开发者对重载new/delete的机制理解有误，误以为需要这样实现才能控制内存分配，但实际上这是错误且无意义的写法。

内容的提问来源于stack exchange，提问作者Dario - Metalcam