为什么有人想要替换operator new 和 operator delete呢？三个常见的理由：
1.用来检测运用上的错误。
如果将“new所的内存”delete却不幸失败，会导致内存泄漏。如果在“new所得内存”身上多次delete会导致不确定行为。如果new持有一串动态分配的所得地址，operator delete将地址从中移走，倒是很容易检测出上述错误用法。此外各式各样的编程错误可能导致数据“overruns”（写入点在分配区块尾端之后）或“underruns”（写入点在分配区块之前）。自定义个operator new，便可以超额分配内存，以额外空间（位于客户所得区块之前或后）放置特定的byte patterns（即签名）。operator delete便得以检查上述签名是否原封不动，若否就表示分配区的某个生命时间点发生了overrun或underrun，这时候operator delete可以志记那个事实以及那个惹事生非的指针。
2.为了强化效果。
缺省的new 和 delete主要用于一般目的，它们必须接纳各种分配形态，范围从程序存活期间的少量区块动态分配，到大数量短命对象的持续分配和归还。还必须考虑破碎问题（fragmentation），无法满足大区块内存需求，即使有总量足够但分散为许多小块的自由内存。
现实存在这么多对内存管理器的需求，因此编译器所带的operator new和operator delete采取中庸之道，它们的工作对每个人都是适度的好，但不对特定任何人有最佳表现。如果你对你的程序的动态内存运用有深刻的了解，通常，定制版的new和delete性能胜过缺省版本。比较快，且需要的内存比较少。
3.为了收集使用上的统计数据。
定制news和deletes之前，理当先收集你的软件如何使用其动态内存。分配区块的大小分布如何？寿命分布如何？倾向于以fifo次序或lifo次序或随机次序来分配和归还？运用形态是否随时间改变，就是软件在不同执行阶段有不同的分配/归还形态吗？任何时候所使用的最大动态分配量是多少？自定义new delete使我们得以轻松收集到这些信息。
下面是个快速发展得出的初阶段global operator new，促进并协助检测“overruns”或“underruns”。
static const int signature = 0xDEADBEEF;
typedef unsigned char Byte;
void* operator new(std::size_t size) throw(std::bad_alloc)
{
using namespace std;
size_t realSize = size + 2*sizeof(int);void* pMem = malloc(realSize);
if(!pMem) throw bad_alloc();
//将signature写入内存的最前段落和最后段落
*(static_cast<int*>(pMem)) = signature;
*(reinterpret_cast<int*>(static_cast<Byte*>(pMem)+realSize-sizeof(int))) = signature;
return static_cast<Byte*>(pMem) + sizeof(int);
}这个operator new的主要缺点在于疏忽了身为这个特殊函数所应该具备的“坚持c++规矩”的态度。条款51说所有operator new都应该内含一个循环，反复调用某个new_handling函数，这里没有。这儿我们暂且忽略之。现在只想专注一个比较微妙的主题：alignment（齐位).
许多计算机系统要求特定的类型必须放在特定的内存地址上。例如可能会要求指针地址必须是4倍数（four-byte aligned）或double是的地址必须是8倍数。如果没有奉行这个条件，可能导致运行期硬件异常。有些系统结构比较慈悲，而是宣称如果齐位条件获得满足，便提供较佳效率。例如Intel x86体系结构上doubles可以对齐于任何byte边界，但如果他是8-byte齐位，其访问速度会快很多。
c++要求所有的operator news返回的指针都有适当的对齐（取决于数据类型），malloc就是在这样的要求下工作，所有operator new返回一个malloc的指针是安全的。然而，我们返回的是一个得自malloc且偏移一个int大小的指针。没人保证它的安全。如果客户端调用operator new企图取得足够一个double所用的内存，而我们在一部“ints为4bytes且double必须8bytes齐位”的机器上跑，我们可能会获得一个未有适当齐位的指针。那可能会造成程序崩溃或速度变慢。
齐位这一类技术细节可以区分出专业质量的内存管理器。写一个总是能够运作的内存管理器并不难，难的是它能够优良的运作。一般在必要地时候才试着写写看。
很多时候不是必要的！某些编译器已经在它们的内存管理函数中切换至调试状态和志记状态（logging）。许多平台上已经有商业产品可以替代编译器自带的内存管理器。
另一个选择是开放源码中的内存管理器。它们对许多平台都可用。boost程序库的pool就是这样一个分配器，它对于最常见的“分配大量小型对象”很有帮助。真正称得上程序库者，必然稳健强固。看看开放源码可能对若干容易忽视的细节取得深刻的理解。TR1支持各类型特定的对齐条件，值得注意。
何时可在“全局性的”或“class专属的”基础上合理替换缺省的new和delete：
为了检测运用错误。前述
为了收集动态分配内存的使用统计信息。前述
为了增加分配和归还的速度。泛型分配器往往比定制的分配器慢，class专属分配器是“区块尺寸固定”之分配器实例，例如boost提供的Pool程序库。如果你的程序是单线程，编译器带的内存分配器具备线程安全，或许可以写个不具线程安全的分配器而大幅改善速度。当然，先分析你的程序，确认瓶颈的确发生在那些内存函数身上。
为了降低缺省内存管理器带来的额外空间开销。泛型内存管理器往往还使用更多内存，常常在每一个分配区块身上招引某些额外开销。针对小型对象而开发的分配器（例如boost的pool）本质上消除了这样的额外开销。
为了弥补缺省分配器中的非最佳齐位（suboptimal alignment）。
为了将相关对象成簇集中。如果你知道特定之某个数据结构往往被一起使用，你又希望在处理这些数据结构时将“内存页错误”（page fault）的频率降至最低，为此数据结构创建另一个heap就有意义，这么一来它们就可以成簇集中在尽可能少的内存页上。new和delete的“placement版本”（条款52）有可能完成这样的集簇行为。
为了获得非传统行为。你会有时候希望operator new和 delete做编译器附带版本没做的某些事情。例如你可能希望分配和归还共享内存（shared memory）内的区块，但唯一能够管理该内存的只有C api函数，那么写下一个定制版的new 和 delete，便得以为c api穿上一件c++外套。也可以写一个自定的operator delete，在其中将所有归还内存内容覆盖为0，藉此增加应用程序的数据安全性。