STL中的智能指针auto_ptr可以实现简单的内存自动回收，防止内存泄漏(memory leakage)。auto_ptr实际是一个类，在该类析构时自动调用delete，从而达到了内存回收的效果。但是，由于同一个指针同一时刻只能被一个auto_ptr占用，如果采用赋值操作（=)或者拷贝构造函数调用，就会发生所有权转移，例如：

此时,p拥有指向一个int的指针，q的指针为空。如果执行q=p；则，p指向空，q指向int；但是，这样所有权转换的问题同样发生在参数传递中，例如

如果调用 foo(p);那么p就丢失了指针，所以一个解决方法是用引用，例如：

两者都是可以的，不过foo1非常不安全，因为在函数里面很容易通过类似赋值的操作使t丢失指针，而foo2不会。例如

会发生编译错误，从而避免灾难的发生。但随之又出现一个很大的问题，就是auto_ptr类的拷贝构造函数，或者赋值函数。最理想的情况是这样(如果能成功，就不会有别的什么问题）：

但由于上述的原因，会发生编译错误（因为调用了release(),而release()会改变成员变量，不再是const)。所以只能去掉const,变为

这样可以编译成功，而且往往也能正确运行，但是唯一的问题是: 当rhs为右值时会出现问题。

为了简化问题，先假设拷贝构造函数什么都不做，即：

auto_ptr(auto_ptr& rhs){}

那么，如果有 auto_ptr<int> p(new int(10))，执行 auto_ptr<int> q(p),不会有任何问题，因为p是左值。但如果执行auto_ptr<int> q(auto_ptr<int>(new int(10))) ,则会发生编译错误，因为auto_ptr<int>(new int(10)) 是右值，对右值的引用只能是常引用，也就是"const auto_ptr& rhs"的形式。但这里要注意的是，刚才那段代码用VC编译没有任何问题，并且可以顺利运行，但是用GCC之类的标准c++就不能顺利编译。

在VC中auto_ptr<int>& p=auto_ptr<int>(new int(0))  是合法的，但在标准C++中是不合法的，只有const auto_ptr<int>& p=auto_ptr<int>(new int(0)) 才是合法的，也即在标准C++中，对右值的引用只能是常引用。所以说，要在标准C++中实现 auto_ptr<int> p(auto_ptr<int>(new int(0))) 就变得不可能了，因为如上所说，拷贝构造函数是这样的形式:auto_ptr(auto_ptr<T>& rhs):ap(rhs.release()){}

但是不能把右值传到一个非常引用中。但毕竟有聪明的人能想到解决办法，利用代理类( proxy class)声明如下结构,为了方便，我用int代替模板参

然后在auto_ptr类中增加了以下函数

之后，如果在标准C++有以下调用（VC中也会按照这个步骤调用，虽然没有auto_ptr_ref它也能直接调用）

auto_ptr<int> p(auto_ptr<int>(new int(0)))

便可以成功，过程如下：

1. 构造临时对象 auto_ptr<int>(new int(0))

2. 想将临时对象通过拷贝构造函数传给p,却发现没有合适的拷贝构造函数，因为只有auto_ptr(auto_ptr& rhs）这个不能用，又没有auto_ptr(const auto_ptr& rhs) （因为用了在所有权转移中会出错）！

3. 编译器只能曲线救国，看看类型转换后能不能传递。

4. 由于我们定义了 operator auto_ptr_ref() 所以编译器自然就可以试一下转为 auto_ptr_ref类型。

5. 编译器猛然间发现，我们定义了 auto_ptr(auto_ptr_ref rhs):ap(rhs.p){} 的构造函数，可以传递。

6. 顺利构造p,任务完成。

其实说白了问题很简单，因为构造函数不能接受右值，则取中间左值=右值， 然后再让函数接受中间左值。 而这一系列过程正是利用编译器能够自动进行类型转换而完成的。