有时我们想这样管理某些对象，要让某种类型的对象能够自我销毁，即“delete this”。很明显这种管理方式需要此类型对象被分配在堆中。而其它一些时候我们想获得一种保障：“不在堆中分配对象，从而保证某种类型的类不会发生内存泄漏。”若在嵌入式系统上工作，就有可能遇到这种情况，发生在嵌入式系统上的内存泄漏是极其严重的，其堆空间是非常珍贵的。有没有可能编写出代码来要求或禁止在堆中产生对象（heap-based object）呢？通常是可以的，不过这种代码也会把“on the heap”的概念搞得比你脑海中所想的要模糊。
要求在堆中建立对象
先从必须在堆中建立对象开始说。为了执行这种限制，必须找到一种方法禁止以调用“new”以外的其它手段建立对象。这很容易做到。非堆对象（non-heap object）在定义它的地方被自动构造，在生存时间结束时自动被释放，所以只要禁止使用隐式的构造函数和析构函数，就可以实现这种限制。
把这些调用变得不合法的一种最直接的方法是把构造函数和析构函数声明为private。这样做副作用太大。没有理由让这两个函数都是private。最好让析构函数成为private，让构造函数成为public。我们可以引进一个专用的伪析构函数，用来访问真正的析构函数。客户端调用伪析构函数释放他们建立的对象。（异常处理体系要求所有在栈中的对象的析构函数必须申明为公有！）
例如，如果我们想仅仅在堆中建立代表unlimited precision numbers（无限精确度数字）的对象，可以这样做：
class UPNumber {
public:
UPNumber();
UPNumber(int initValue);
UPNumber(double initValue);
UPNumber(const UPNumber& rhs);
// 伪析构函数 (一个const 成员函数， 因为即使是const对象也能被释放。)
void destroy() const { delete this; }
...
private:
~UPNumber();
};
然后客户端这样进行程序设计：
UPNumber n; // 错误! (在这里合法， 但是
// 当它的析构函数被隐式地
// 调用时，就不合法了)
UPNumber *p = new UPNumber; //正确
delete p; // 错误! 试图调用private 析构函数
p->destroy(); // 正确
另一种方法是把全部的构造函数都声明为private。这种方法的缺点是一个类经常有许多构造函数，类的作者必须记住把它们都声明为private。否则如果这些函数就会由编译器生成，构造函数包括拷贝构造函数，也包括缺省构造函数；编译器生成的函数总是public。因此仅仅声明析构函数为private是很简单的，因为每个类只有一个析构函数。
通过限制访问一个类的析构函数或它的构造函数来阻止建立非堆对象，但是这种方法也禁止了继承和包容（containment）：
class UPNumber { ... }; // 声明析构函数或构造函数
// 为private
class NonNegativeUPNumber:
public UPNumber { ... }; // 错误! 析构函数或
//构造函数不能编译
class Asset {
private:
UPNumber value;
// 错误! 析构函数或构造函数不能编译
};
这些困难不是不能克服的。通过把UPNumber的析构函数声明为protected（同时它的构造函数还保持public）就可以解决继承的问题，需要包含UPNumber对象的类可以修改为包含指向UPNumber的指针：
class UPNumber { ... }; // 声明析构函数为protected
class NonNegativeUPNumber:
public UPNumber { ... }; // 现在正确了; 派生类
// 能够访问protected 成员
class Asset {
public:
Asset(int initValue);
~Asset();
...
private:
UPNumber *value;
};
Asset::Asset(int initValue)
: value(new UPNumber(initValue)) // 正确
{ ... }
Asset::~Asset()
{ value->destroy(); } // 也正确
判断一个对象是否在堆中
如果我们采取这种方法，我们必须重新审视一下“在堆中”这句话的含义。上述粗略的类定义表明一个非堆的NonNegativeUPNumber对象是合法的：
NonNegativeUPNumber n; // 正确
那么现在NonNegativeUPNumber对象n中的UPNumber部分也不在堆中，这样说对么？答案要依据类的设计和实现的细节而定，但是让我们假设这样说是不对的，所有UPNumber对象 —即使是做为其它派生类的基类—也必须在堆中。我们如何能强制执行这种约束呢？
没有简单的办法。UPNumber的构造函数不可能判断出它是否做为堆对象的基类而被调用。也就是说对于UPNumber的构造函数来说没有办法侦测到下面两种环境的区别：
NonNegativeUPNumber *n1 =
new NonNegativeUPNumber; // 在堆中
NonNegativeUPNumber n2; //不再堆中
也许你想你能够在new操作符、operator new和new 操作符调用的构造函数的相互作用中玩些小把戏。可可以这样修改UPNumber，如下所示：
class UPNumber {
public:
// 如果建立一个非堆对象，抛出一个异常
class HeapConstraintViolation {};
static void * operator new(size_t size);
UPNumber();
...
private:
static bool onTheHeap; //在构造函数内，指示
//对象是否被构造在堆上
};
// obligatory definition of class static
bool UPNumber::onTheHeap = false;
void *UPNumber::operator new(size_t size)
{
onTheHeap = true;
return ::operator new(size);
}
UPNumber::UPNumber()
{
if (!onTheHeap) {
throw HeapConstraintViolation();
}
proceed with normal construction here;
onTheHeap = false; // 为下一个对象清除标记
}
如果不再深入研究下去，就不会发现什么错误。这种方法利用了这样一个事实：“当在堆上分配对象时，会调用operator new来分配raw memory”，operator new设置onTheHeap为true，每个构造函数都会检测onTheHeap，看对象的raw memory是否被operator new所分配。如果没有，一个类型为HeapConstraintViolation的异常将被抛出。否则构造函数如通常那样继续运行，当构造函数结束时，onTheHeap被设置为false，然后为构造下一个对象而重置到缺省值。
这是一个非常好的方法，但是不能运行。请考虑一下这种可能的客户端代码：
UPNumber *numberArray = new UPNumber[100];
第一个问题是为数组分配内存的是operator new[]，而不是operator new，不过（倘若你的编译器支持它）你能象编写operator new一样容易地编写operator new[]函数。更大的问题是numberArray有100个元素，所以会调用100次构造函数。但是只有一次分配内存的调用，所以100个构造函数中只有第一次调用构造函数前把onTheHeap设置为true。当调用第二个构造函数时，会抛出一个异常，你真倒霉。
即使不用数组，bit-setting操作也会失败。考虑这条语句：
UPNumber *pn = new UPNumber(*new UPNumber);
这里我们在堆中建立两个UPNumber，让pn指向其中一个对象；这个对象用另一个对象的值进行初始化。这个代码有一个内存泄漏，我们先忽略这个泄漏，这有利于下面对这条表达式的测试，执行它时会发生什么事情：
new UPNumber(*new UPNumber)
它包含new 操作符的两次调用，因此要调用两次operator new和调用两次UPNumber构造函数。程序员一般期望这些函数以如下顺序执行：
调用第一个对象的operator new
调用第一个对象的构造函数
调用第二个对象的operator new
调用第二个对象的构造函数
但是C++语言没有保证这就是它调用的顺序。一些编译器以如下这种顺序生成函数调用：
调用第一个对象的operator new
调用第二个对象的operator new
调用第一个对象的构造函数
调用第二个对象的构造函数
编译器生成这种代码丝毫没有错，但是在operator new中set-a-bit的技巧无法与这种编译器一起使用。因为在第一步和第二步设置的bit，第三步中被清除，那么在第四步调用对象的构造函数时，就会认为对象不再堆中，即使它确实在。
这些困难没有否定让每个构造函数检测*this指针是否在堆中这个方法的核心思想，它们只是表明检测在operator new(或operator new[])里的bit set不是一个可靠的判断方法。我们需要更好的方法进行判断。
例如你决定利用一个在很多系统上存在的事实，程序的地址空间被做为线性地址管理，程序的栈从地址空间的顶部向下扩展，堆则从底部向上扩展：
在以这种方法管理程序内存的系统里（很多系统都是，但是也有很多不是这样），你可能会想能够使用下面这个函数来判断某个特定的地址是否在堆中：
// 不正确的尝试，来判断一个地址是否在堆中
bool onHeap(const void *address)
{
char onTheStack; // 局部栈变量
return address < &onTheStack;
}
这个函数背后的思想很有趣。在onHeap函数中onTheSatck是一个局部变量。因此它在堆栈上。当调用onHeap时，它的栈框架（stack frame）(也就是它的activation record)被放在程序栈的顶端，因为栈在结构上是向下扩展的（趋向低地址），onTheStack的地址肯定比任何栈中的变量或对象的地址小。如果参数address的地址小于onTheStack的地址，它就不会在栈上，而是肯定在堆上。
到目前为止，这种逻辑很正确，但是不够深入。最根本的问题是对象可以被分配在三个地方，而不是两个。是的，栈和堆能够容纳对象，但是我们忘了静态对象。静态对象是那些在程序运行时仅能初始化一次的对象。静态对象不仅仅包括显示地声明为static的对象，也包括在全局和命名空间里的对象。这些对象肯定位于某些地方，而这些地方既不是栈也不是堆。
它们的位置是依据系统而定的，但是在很多栈和堆相向扩展的系统里，它们位于堆的底端。先前内存管理的图片到讲述的是事实，而且是很多系统都具有的事实，但是没有告诉我们这些系统全部的事实，加上静态变量后，这幅图片如下所示：
onHeap不能工作的原因立刻变得很清楚了，不能辨别堆对象与静态对象的区别：
void allocateSomeObjects()
{
char *pc = new char; // 堆对象: onHeap(pc)
// 将返回true
char c; // 栈对象: onHeap(&c)
// 将返回false
static char sc; // 静态对象: onHeap(&sc)
// 将返回true
...
}
现在你可能不顾一切地寻找区分堆对象与栈对象的方法，在走头无路时你想在可移植性上打主意，但是你会这么孤注一掷地进行一个不能获得正确结果的交易么？绝对不会。我知道你会拒绝使用这种虽然诱人但是不可靠的“地址比对”技巧。
令人伤心的是不仅没有一种可移植的方法来判断对象是否在堆上，而且连能在多数时间正常工作的“准可移植”的方法也没有。如果你实在非得必须判断一个地址是否在堆上，你必须使用完全不可移植的方法，其实现依赖于系统调用，只能这样做了。因此你最好重新设计你的软件，以便你可以不需要判断对象是否在堆中。
如果你发现自己实在为对象是否在堆中这个问题所困扰，一个可能的原因是你想知道对象是否能在其上安全调用delete。这种删除经常采用“delete this”这种声明狼籍的形式。不过知道“是否能安全删除一个指针”与“只简单地知道一个指针是否指向堆中的事物”不一样，因为不是所有在堆中的事物都能被安全地delete。再考虑包含UPNumber对象的Asset对象：
class Asset {
private:
UPNumber value;
...
};
Asset *pa = new Asset;
很明显*pa（包括它的成员value）在堆上。同样很明显在指向pa->value上调用delete是不安全的，因为该指针不是被new返回的。
幸运的是“判断是否能够删除一个指针”比“判断一个指针指向的事物是否在堆上”要容易。因为对于前者我们只需要一个operator new返回的地址集合。因为我们能自己编写operator new函数，所以构建这样一个集合很容易。如下所示，我们这样解决这个问题：
void *operator new(size_t size)
{
void *p = getMemory(size); //调用一些函数来分配内存，
//处理内存不够的情况
把 p加入到一个被分配地址的集合;
return p;
}
void operator delete(void *ptr)
{
releaseMemory(ptr); // return memory to
// free store
从被分配地址的集合中移去ptr;
}
bool isSafeToDelete(const void *address)
{
返回address是否在被分配地址的集合中;
}
这很简单，operator new在地址分配集合里加入一个元素，operator delete从集合中移去项目，isSafeToDelete在集合中查找并确定某个地址是否在集合中。如果operator new 和 operator delete函数在全局作用域中，它就能适用于所有的类型，甚至是内建类型。
在实际当中，有三种因素制约着对这种设计方式的使用。第一是我们极不愿意在全局域定义任何东西，特别是那些已经具有某种含义的函数，象operator new和operator delete。正如我们所知，只有一个全局域，只有一种具有正常特征形式（也就是参数类型）的operator new和operator delete