探究c++智能指针中auto_ptr_ref的存在意义

　　最近开始拜读侯捷先生翻译的《C++标准程序库》，看到智能指针的最后对于auto_ptr_ref的存在有点迷糊，感觉书上没有讲透它的存在意义，花了一个下午的时间查阅相关资料，才算是稍微清晰了一些。在这里我假设大家都阅读过这本书的auto_ptr相关知识了，如果不太明白可以去看考该书第四章的相关部分。

　　我们知道，auto_ptr的一大特点就是对于下属数据的唯一控制权，也就是说不准多个auto_ptr控制同一个数据，这样当auto_ptr被删除时，其控制数据也被删除，这时我们再引用其他的auto_ptr时就会出现严重的问题，因此auto_ptr在进行复制构造或者是赋值的时候会进行一个操作：控制权转移。看下面的代码：

auto_ptr<int> p(new int(3));
auto_ptr<int> q(p);

cout << "p = " << p.get() << " q = " << q.get() << endl;

　　最终输出时，p的结果为0，而q的结果为3的地址（get方法获得的是数据的地址），这说明在复制构造的过程中p将数据的控制权转交给了q，因此p里面是空的。同样，赋值操作会带来相同的结果。

auto_ptr<int> p(new int(3));
auto_ptr<int> q = p;

cout << "p = " << p.get() << " q = " << q.get() << endl;

　　我们注意到，目前的所有代码auto_ptr都是作为左值出现的，那如果auto_ptr作为右值出现的话会是什么样的情况呢？比如下面的这据代码：

auto_ptr<int> p(auto_ptr<int>(new int(3)));

　　如果要是没有auto_ptr_ref的话，在标准c++环境下进行编译，这句代码连编译都过不去，原因就是非常量引用不可以做右值。这是在c++设计之初规定的，因为右值如果是非常量引用（references-to-non-const）会导致一些程序员们不想看到的情况发生。（具体可以参见More Effective c++的Item19，不过针对一些朋友可能找不到的情况，我在文章最后做了一下解释，想要看的朋友可以直接翻到最后先看看）

　　而在auto_ptr的设计过程中，因为考虑到控制权转移的问题，在进行复制构造和赋值重载的时候右值不是auto_ptr& const rsh，而是auto_ptr& rsh，下面给出c++STL的相关源代码：

typedef auto_ptr<_Ty> _Myt;

explicit auto_ptr(_Ty *_Ptr = 0) _THROW0()
    : _Myptr(_Ptr)
    {    // construct from object pointer
    }

auto_ptr(_Myt& _Right) _THROW0()
    : _Myptr(_Right.release())
    {    // construct by assuming pointer from _Right    auto_ptr
    }

　　在定义auto_ptr的复制构造函数时，没有使用const声明，这是为了能够顺利调用到右值的release()函数，将右值的数据控制权释放掉，release()会返回数据的指针并交给左值进行管理。而auto_ptr_ref的存在正是为了解决这个困扰人的问题，它作为一个中间左值解决了这个问题。（要不是c++的设计者们想到了这个方法，也许stl中就不会存在auto_ptr这个东西了）

　　为了便于理解auto_ptr_ref，这里给出auto_ptr_ref在STL中的定义代码：

// TEMPLATE CLASS auto_ptr
template<class _Ty>
    class auto_ptr;

template<class _Ty>
    struct auto_ptr_ref
        {    // proxy reference for auto_ptr copying
    explicit auto_ptr_ref(_Ty *_Right)
        : _Ref(_Right)
        {    // construct from generic pointer to auto_ptr ptr
        }

    _Ty *_Ref;    // generic pointer to auto_ptr ptr
    };

　　结构其实非常简单，它只保存了一个数据指针，并且其构造函数被声明为了explicit（显示构造），c++的设计者们同时还向auto_ptr中加入了这个方法：

template<class _Other>
        operator auto_ptr_ref<_Other>() _THROW0()
        {    // convert to compatible auto_ptr_ref
        _Other *_Cvtptr = _Myptr;    // test implicit conversion
        auto_ptr_ref<_Other> _Ans(_Cvtptr);
        _Myptr = 0;    // pass ownership to auto_ptr_ref
        return (_Ans);
        }

auto_ptr(auto_ptr_ref<_Ty> _Right) _THROW0()
        {    // construct by assuming pointer from _Right auto_ptr_ref
        _Ty *_Ptr = _Right._Ref;
        _Right._Ref = 0;    // release old
        _Myptr = _Ptr;    // reset this
        }

　这两段代码很重要，我们来模拟一下编译器的编译过程，就拿最开始我们编译不过去的那句话作为例子：

　　auto_ptr<int> p(auto_ptr<int>(new int(3)));

1、编译器首先处理auto_ptr<int>(new int(3))，这里面生成了一个临时变量，这个变量作为左值参加了本次运算，并且包含了数据3
2、编译器将临时变量丢给auto_ptr<int> p()中继续构造，但是auto_ptr中并没有auto_ptr(auto_ptr& const rsh)这个方法，于是编译器就没有办法了···
3、这时候编译器开始尝试用其他方法解决问题，它注意到了有一个operator是 auto_ptr_ref<int>()的东西，于是编译器尝试隐式转换是否能够成功，这次它成功了，并且产生了一个auto_ptr_ref
4、编译器将auto_ptr_ref甩给auto_ptr<int> p()继续尝试构造，这时候编译器发现有一个方法auto_ptr(auto_ptr_ref<_Ty> _Right)，而且这里面的参数不是引用，而是常值调用，编译器非常高兴的将auto_ptr_ref交给auto_ptr从而完成了构造

　　这样一来编译器通过绕了一个圈，就把这个问题给解决了···最关键的地方还是通过一个隐式的转换从而避开了非常量引用不能作为左值的问题。既然复制构造能够解决，那赋值操作也是可以的：

_Myt& operator=(auto_ptr_ref<_Ty> _Right) _THROW0()
        {    // assign compatible _Right._Ref (assume pointer)
        _Ty *_Ptr = _Right._Ref;
        _Right._Ref = 0;    // release old
        reset(_Ptr);    // set new
        return (*this);
        }

　　同样的原理，转换后绕过const做到了这一点，就完成了赋值操作了。所以说这个auto_ptr_ref的存在意义就是通过规避非常值引用不能作为右值这么个事情才存在的，理解了这一点，auto_ptr_ref存在的意义就会清晰一点了。

 

注：关于非常量引用不能作为左值的问题

　　本文章中涉及到了中间变量这么一个东西，就是在auto_ptr<int> p(auto_ptr<int>(new int(3)))这句话里面，编译器第一次是生成了一个中间变量，然后传入到p的构造中去尝试。大多数人都把中间变量当做const看，倒是也可以，因为是const类型，因此也无法传入auto_ptr的那个非const复制构造中去。

　　但是中间变量这个东西也是可以被赋值的···所以又有另一种解释方法，c++在设计之初考虑，一个参数如果是以非常值引用的形式进入方法内部，那么编译器有理由相信这个值可以被更改，并且在方法结束后，这个被修改的引用还是有可能会发挥作用，为了防止修改导致的无法预料的错误，编译器要求右值是不能被修改的，rsh中的r解释成read就可以很好的表示这个意思了。而中间变量作为一个参数传递到方法中后用完就被抛弃了，修改它也没什么意义了···因此c++在设计时就要求不准修改中间变量以避免一些非常规的错误发生。