zz:剖析C++标准库智能指针(std::auto_ptr)

http://blog.csdn.net/arau_sh/article/details/5856985

 

1. Smart Pointer,中文名：智能指针, 舶来品?

不可否认,资源泄露(resource leak)曾经是C++程序的一大噩梦.垃圾回收机制(Garbage Collection)一时颇受注目.然而垃圾自动回收机制并不能满足内存管理的即时性和可视性,往往使高傲的程序设计者感到不自在.况且,C++实现没有引入这种机制.在探索中,C++程序员创造了锋利的"Smart Pointer".一定程度上,解决了资源泄露问题.

也许,经常的,你会写这样的代码：(//x拟为class:)

view plain

1. class x{ 
2. public:         
3. int m_Idata; 
4. public: 
5. x(int m_PARAMin):m_Idata(m_PARAMin){} 
6. void print(){ cout<<m_Idata<<endl; } 
7. ..... 
8. } 
9. void fook(){ 
10. x* m_PTRx = new A(m_PARAMin); 
11. m_PTRx->DoSomething(); 
12. delete m_PTRx; 
13. } 

是的,这里可能没什么问题.可在复杂、N行、m_PTRclassobj所指对象生命周期要求较长的情况下,你能保证你不会忘记delete m_PTRclassobj吗?生活中,我们往往不应该有太多的口头保证,我们需要做些真正有用的东西.还有一个更敏感的问题：异常.假如在#2方法执行期异常发生,函数执行终止,那么new出的对象就会泄露.于是,你可能会说：那么就捕获异常来保证安全性好了.
你写这样的程式：

view plain

1. void fook() 
2. { 
3.       A* m_PTRx = new x(m_PARAMin); 
4. try
5.       { 
6.           m_PTRx->DoSomething(); 
7.       } 
8. catch(..) 
9.       { 
10. delete m_PTRx; 
11. throw; 
12.       } 
13. delete m_PTRx; 
14. } 

哦!天哪!想象一下,你的系统,是否会象专为捕获异常而设计的. 一天,有人给你建议:"用Smart Pointer,那很安全.".你可以这样重写你的程序：

view plain

1. void fook() 
2. { 
3.       auto_ptr<x> m_SMPTRx(new x(m_PARAMin)); 
4.       m_SMPTRx->DoSomething(); 
5. } 

OK!你不太相信.不用delete吗?是的.不用整天提心吊胆的问自己:"我全部delete了吗?",而且比你的delete策略更安全.

然后,还有人告诉你,可以这样用呢：

view plain

1. ok1. 
2.       auto_ptr<x> m_SMPTR1(new x(m_PARAMin));  
3.       auto_ptr<x> m_SMPTR2(m_SMPTR1);  //#2
4.       May be you can code #2 like this : 
5.       auto_ptr<x> m_SMPTR2; 
6.       m_SMPTR2 = m_SMPTR1;       
7. ok2. 
8.       auto_ptr<int> m_SMPTR1(new int(32)); 
10. ok3. 
11.       auto_ptr<int> m_SMPTR1; 
12.       m_SMPTR1 = auto_ptr<int>(new int(100)); 
13.       也可以： 
14.       auto_ptr<int> m_SMPTR1(auto_ptr<int>(new int(100))); 
16. ok4. 
17.       auto_ptr<x> m_SMPTR1(new x(m_PARAMin)); 
18.       m_SMPTR1.reset(new x(m_PARAMin1)); 
20. ok5. 
21.       auto_ptr<x> m_SMPTR1(new x(m_PARAMin)); 
22.       auto_ptr<x> m_SMPTR2(m_SMPTR.release()); 
23.       cout<<(*m_SMPTR2).m_Idata<<endl;   
25. ok6. 
26.       auto_ptr<int> fook() 
27.       { 
28. return auto<int>(new int(100)); 
29.       } 
30. ok7.............and so on 

但不可这样用：

view plain

1. no1.    
2. char* chrarray = new char[100]; 
3.       strcpy(chrarray,"I am programming."); 
4.       auto_ptr<char*> m_SMPTRchrptr(chrarray); 
5. //auto_ptr并不可帮你管理数组资源    
7. no2. 
8.       vector<auto_ptr<x>> m_VECsmptr; 
9.       m_VECsmptr.push_back(auto_ptr<int>(new int(100))); 
10. //auto_ptr并不适合STL内容.
12. no3. 
13. const auto_ptr<x> m_SMPTR1(new x(100)); 
14.       auto_ptr<x> m_SMPTR(new x(200)); 
16. no4. 
17.       x m_OBJx(300); 
18.       auto_ptr<x> m_SMPTR(&m_OBJx); 
20. no5 
21.       x* m_PTR = new x(100); 
22.       auto_ptr<x> m_SMPTR = m_pTR; 
23. no6..........and so on 

预先提及所有权的问题,以便下面带着疑问剖析代码?

view plain

1. power1. 
2.       auto_ptr<x> m_SMPTR1(new x(100)); 
3.       auto_ptr<x> m_SMPTR2 = m_SMPTR1; 
4.       m_SMPTR2->print(); 
5. //输出：100.
6.       m_SMPTR1->print(); 
7. //!! 非法的.
8. power2. 
9.       auto_ptr<x> m_SMPTR(new x(100));       
10.       auto_ptr<x> returnfun(auto_ptr<x> m_SMPTRin) 
11.       { 
12. return m_SMPTRin; 
13.       } 
15.       auto_ptr<x> = returnfun(m_SMPTR); 

//在上面的#5中,我要告诉你对象所有权转移了两次.
//什么叫对象所有权呢?

2. std::auto_ptr的设计原理

上面的一片正确用法,它们在干些什么?

一片非法,它们犯了什么罪?

一片什么所有权转移,它的内部机智是什么?

哦!一头雾水?下面我们就来剖析其实现机制.

基础知识：

a.智能指针的关键技术：在于构造栈上对象的生命期控制堆上构造的对象的生命期.因为在智能指针的内部,存储着堆对象的指针,而且在构析函数中调用delete行为.大致机构如下：

view plain

1. x* m_PTRx = new x(100);//#1
2. template<typename T> auto_ptr 
3. { 
4. private: 
5.       T* m_PTR;//维护指向堆对象的指针,在auto_ptr定位后    
6. //它应该指向#1构造的对象,即拥有所有权.
7.       ~auto_ptr(){ delete m_PTR; } 
8.       .... 
9. } 

b.所有权转移之说

上面曾有一非法的程式片段如下：

    auto_ptr<x> m_SMPTR1(new x(100));

    auto_ptr<x> m_SMPTR2 = m_SMPTR1;

    m_SMPTR2->print();

    //输出：100.

    m_SMPTR1->print();

    //!! 非法的.

按常理来说,m_SMPTR->print();怎么是非法的呢?

那是因为本来,m_SMPTR1维护指向new x(100)的指针,可是m_SMPTR2 = m_SMPTR1;auto_ptr内部机制使得m_SMPTR1将对象的地址传给m_SMPTR2,而将自己的对象指针置为0.那么自然m_SMPTR->print();失败.这里程序设计者要负明显的职责的.那么auto_ptr为什么采取这样的策略：保证所有权的单一性.亦保证了系统安全性.如果多个有全权的auto_ptr维护一个对象,那么在你消除一个auto_ptr时,将导致多个auto_ptr的潜在危险.

下面我们以SGI-STL的auto_ptr设计为样本(去掉了无关分析的宏),来剖析其原理.

view plain

1. template <class _Tp> class auto_ptr { 
2. private: 
3.     Tp* _M_ptr;  //定义将维护堆对象的指针
4. public: 
5.    #5  typedef _Tp element_type;  //相关类型定义
6.    #6  explicit auto_ptr(_Tp* __p = 0) __STL_NOTHROW : _M_ptr(__p) {}
7.    #7  auto_ptr(auto_ptr& __a) __STL_NOTHROW : _M_ptr(__a.release()) {}
8.    #8  template <class _Tp1> auto_ptr(auto_ptr<_Tp1>& __a) __STL_NOTHROW
9.                                                  : _M_ptr(__a.release()) {} 
10. //#6、#7、#8是auto_ptr构造函数的三个版本.
11. //#6注释：传入对象的指针,构造auto_ptr.explicit关键字:禁止隐式转换.
12. //        这就是ok2正确,而no5(隐式转换)错误的原因.
13. //#7注释：拷贝构造函数.
14. //        传入auto_ptr实例,构造auto_ptr. ok1、ok3使用了这个构造式.
15. //        它是一个很关键的构造函数,在具体情况下,我们再分析
16. //#8注释：auto_ptr的模板成员,可在继承对象重载的基础上,实现特殊功能.
17. //  
18. //   举例：
19. //   class A{ public:
20. //          virtual void fook(){cout<<"I am programming"<<endl;
21. //          /*..........*/                                   };
22. //   class B : public A {
23. //          virtual void fook(){ cout<<"I am working"<<endl;
24. //         /*...........*/                                  }; 
25. //   auto_ptr<A> m_SMPTRa(new A(33));//实质：
26. //   auto_ptr<B> m_SMPTRb(m_SMPTRa); //基类的指针可以赋给派生类的指针         
27. //             
28. //   auto_ptr<B> m_SMPTRb(new B(44));//实质：
29. //   auto_ptr<A> m_SMPTRa(m_SMPTRb); //派生类的指针不可赋给基类的指针
30. //      
31. //   auto_ptr<A> m_SMPTRa(new B(33));  // ok! 
32. //   m_SMPTRa->fook()将调用派生类B的fook()
33. //   m_SMPTRa->A::fook()将调用基类A的fook()
34. //   
35. //   auto_ptr<B> m_SMPTRb(new A(33));  // wrong!
36. //  
37. //  
38.    #9  auto_ptr& operator=(auto_ptr& __a) __STL_NOTHROW {
39.    #10 if (&__a != this) { delete _M_ptr;  _M_ptr = __a.release(); }
40.    #11 return *this;
41.    #12}
43.    #13 template <class _Tp1>
44.    #14 auto_ptr& operator=(auto_ptr<_Tp1>& __a) __STL_NOTHROW {
45.    #15 if (__a.get() != this->get()) { delete _M_ptr; _M_ptr = __a.release(); }
46.    #16 return *this;
47.    #16 } 
48. //
49. // #9~~#16 两个版本的指派函数.
50. //         delete _M_ptr; 在指派前,销毁原维护的对象.
51. //         _a.release() ; release操作,详细代码参见#20~~#23.
52. //                        用于*this获得被指派对象,
53. //                        且将原维护auto_ptr置空.
54. //     no3使用了第一种指派.
55. //     而权限转移正是_a.release()的结果.
57.    #17 ~auto_ptr() __STL_NOTHROW { delete _M_ptr; }
58. //构析函数.消除对象.注意这里对对象的要求!
60.    #17 _Tp& operator*() const __STL_NOTHROW {  return *_M_ptr; }
61.    #18 _Tp* operator->() const __STL_NOTHROW { return _M_ptr;  }
62.    #19 _Tp* get() const __STL_NOTHROW { return _M_ptr; }
63. //
64. //  操作符重载.
65. // #17注释：提领操作(dereference),获得对象. 见ok5用法.
66. // #18注释：成员运算符重载,返回对象指针.
67. // #19注释：普通成员函数.作用同于重载->运算符
68. //
69.    #20 _Tp* release() __STL_NOTHROW {
70.    #21 _Tp* __tmp = _M_ptr;
71.    #22 _M_ptr = 0;
72.    #23 return __tmp;                }
73. //上面已经详解     
75.    #24 void reset(_Tp* __p = 0) __STL_NOTHROW {
76.    #25 delete _M_ptr;
77.    #26 _M_ptr = __p;                          }
78. //
79. //传入对象指针,改变auto_ptr维护的对象
80. //且迫使auto_ptr消除原来维护的对象
81. //见ok3用法.
82. // According to the C++ standard, these conversions are required.  Most
83. // present-day compilers, however, do not enforce that requirement---and,
84. // in fact, most present-day compilers do not support the language
85. // features that these conversions rely on.

//下面这片段用于类型转化,目前没有任何编译器支持具体技术细节不诉.  

view plain

1. #ifdef __SGI_STL_USE_AUTO_PTR_CONVERSIONS
2. #27 private:
3. #28 template<class _Tp1>
4. #29 struct auto_ptr_ref { _Tp1* _M_ptr; auto_ptr_ref(_Tp1* __p) : _M_ptr(__p) {}};
5. #30 public:
6. #31 auto_ptr(auto_ptr_ref<_Tp> __ref) __STL_NOTHROW
7.                                : _M_ptr(__ref._M_ptr) {} 
8. #32 template <class _Tp1>
9. #33 operator auto_ptr_ref<_Tp1>() __STL_NOTHROW
10. #34 { return auto_ptr_ref<_Tp>(this->release()); }
11. #35 template <class _Tp1> operator auto_ptr<_Tp1>() __STL_NOTHROW
12. #36 { return auto_ptr<_Tp1>(this->release()); }
13. #37 #endif /* __SGI_STL_USE_AUTO_PTR_CONVERSIONS */
14. #38 };

OK!就是这样了.
      正如上面原理介绍处叙说,
      你需要正视两大特性：
      1.构造栈对象的生命期控制堆上构造的对象的生命期
      2.通过release来保证auto_ptr对对象的独权.
在我们对源码分析的基础上,重点看看：
no系列错误在何处?
     no1.
         我们看到构析函数template<class _Tp>
                         ~auto_ptr() _STL_NOTHROW
                        { delete _M_ptr; }
         所以它不能维护数组,
         维护数组需要操作：delete[] _M_ptr;
     no2.
        先提部分vector和auto_ptr代码：
        a.提auto_ptr代码

view plain

1. auto_ptr(auto_ptr& __a) __STL_NOTHROW : _M_ptr(__a.release()) {} 

b.提vector代码

view plain

1. Part1: 
2. void push_back(const _Tp& __x) { 
3. if (_M_finish != _M_end_of_storage) { 
4.             construct(_M_finish, __x); 
5.             ++_M_finish; 
6.             } 
7. else
8.              _M_insert_aux(end(), __x); 
9.           } 
11.          Part2: 
12. template <class _T1, class _T2> 
13. inline void construct(_T1* __p, const _T2& __value) {new (__p) _T1(__value);} 
15.          Part3. 
16. template <class _Tp, class _Alloc> 
17. void
18.          vector<_Tp, _Alloc>::_M_insert_aux 
19.          (iterator __position, const _Tp& __x) 
20.          { 
21. if (_M_finish != _M_end_of_storage) { 
22.                 construct(_M_finish, *(_M_finish - 1)); 
23.                 ++_M_finish; 
24. //++++++++++++++++++++++++++++++++
25. //     _Tp __x_copy = __x;       +
26. //++++++++++++++++++++++++++++++++
27.                 copy_backward(__position, _M_finish - 2, _M_finish - 1); 
28.                 *__position = __x_copy; 
29.             } 
30. else
31.         { 
32. const size_type __old_size = size(); 
33. const size_type __len = __old_size != 0 ? 2 * __old_size : 1; 
34.                 iterator __new_start = _M_allocate(__len); 
35.                 iterator __new_finish = __new_start; 
36.                 __STL_TRY { 
37.                     __new_finish = uninitialized_copy 
38.                     (_M_start, __position, __new_start); 
39.                     construct(__new_finish, __x); 
40.                     ++__new_finish; 
41.                     __new_finish = uninitialized_copy 
42.                     (__position, _M_finish, __new_finish); 
43.                 } 
44.                 __STL_UNWIND((destroy(__new_start,__new_finish),  
45.                         _M_deallocate(__new_start,__len))); 
46.                     destroy(begin(), end()); 
47.                     _M_deallocate(_M_start, _M_end_of_storage - _M_start); 
48.                     _M_start = __new_start; 
49.                     _M_finish = __new_finish; 
50.                     _M_end_of_storage = __new_start + __len; 
51.             } 
52.        } 

从提取的vector代码,Part1可看出,push_back的操作行为.
兵分两路,可是再向下看,你会发现,无一例外,都通过const _Tp& 进行拷贝行为,那么从auto_ptr提出的片段就派上用场了. 可你知道的,auto_ptr总是坚持对对象的独权.那必须修改原来维护的对象,而vector行为要求const _Tp&,这样自然会产生问题.一般编译器是可以发觉这种错误的.

其实,STL所有的容器类都采用const _Tp&策略.
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 看了sutter和Josuttis的两篇文章中,都提及：                                                         +
+ STL容器不支持auto_ptr原因在于copy的对象只是获得所有权的对象,                      +
+ 这种对象不符合STL的要求.可是本人总感觉即时不是真正的复制对象,                    +
+ 但我用vector<auto_ptr<x> >的目的就在于维护对象,并不在乎                              +
+ 所谓的完全对象.而且我用自己写的Smart Pointer配合STL容器工作,                       +
+ 很正常.那需要注意的仅仅是const问题.                                                               +
+                                                                                                                       +
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    no3.
  这个也是auto_ptr隐含的所有权问题引起的.const auto_ptr不允许修改.
  随便提及：const对象不代表对象一点不可以改变.在两种const语义下,都有方法修改对象或对象内部指针维护的对象或其它资源.

  no4.
  再看auto_ptr的构析函数.delete不可以消除栈上资源.

  no5.
  依赖传入对象指针的构造函数被声明为explicit,禁止隐式转换.

3.auto_ptr高级使用指南

  a.类成员auto_ptr,禁止构造函数以构建"完全对象"

view plain

1. Programme1: 
2. struct Structx{ 
3. int m_Idata; 
4. char m_CHRdata; 
5. /* and so on */
6.         }; 
7.         出于对象编程的理念, 
8.         我们将Structx打造成包裹类： 
9. class StructWrapper{ 
10. private: 
11.         Structx* m_STRTxptr; 
12. public: 
13.         StructWrapper():m_STRTxptr(new Structx){} 
14.         ~StructWrapper(){delete m_SMRTxptr; } 
15. public: 
16. void Soperator1(){ /* 针对Structx对象的特性操作 */} 
17. void Soperator2(){ /* 针对Structx对象的特性操作 */}         
18. /*  and so on */
19.         };  
21.         Programme2: 
22. class StructWrapper{ 
23. private: 
24.         auto_ptr<Structx> m_SMPTRx; 
25. public: 
26.         StructWrapper():m_SMPTRAx(new Structx){} 
27. public: 
28. void Soperator1(){ /* 针对Structx对象的特性操作 */} 
29. void Soperator2(){ /* 针对Structx对象的特性操作 */}         
30. /*  and so on */
31.         };  
33.         Programme3: 
34.         StructWrapper::StructWrapper(const StructWrapper& other) 
35.         : M_SMPTRx(new Struct(*other.m_SMPTRx)) { } 
36.         StructWrapper& StructWrapper::operator=(const StructWrapper &other){ 
37.         *m_SMPTRx = *other.m_SMPTRx; 
38.         }; 

处于对构建于堆中的对象(new Structx)智能维护的需要.我们将programme1改造为programme2：不错,对象是可以智能维护了.对于包裹类(StructWrapper)你是否会有这样的构造或指派操作：
StructWrapper m_SMPTRWrapper2(m_SMPTRWrapper1);
StructWrapper mSMPTRWrapper2 = m_SMPTRWrapper1; 
那么请注意：
当你坦然的来一个：M_SMPTRWrapper1->Soperator1();的时候,系统崩溃了.不必惊讶,所有权还是所有权问题.问一下自己：当programme2默认拷贝构造函数作用时,又调用了auto_ptr的默认构造函数,那么auto_ptr所有的默认行为都遵循独权策略.对,就这样.m_SMPTRWrapper1的对象所有权转移给了m_SMPTRWrapper2.M_SMPTRWrapper1->Soperator1();那么操作变成了在NULL上的.哦!系统不崩溃才怪.那么你需要想,programme3那样利用auto_ptr的提领操作符自己的构造"完全对象".

b.利用const关键字,防止不经意的权限转移
从上面的叙述,你可看出,所有权转移到处可以酿成大祸.而对于一般应用来说,独权又是很好的安全性策略.那么我们就用const来修饰auto_ptr,禁止不经意的错误.
当然上面提及：并不代表auto_ptr是不可修改的.处于需要,从两种const语义,你都可实现修改.然,你还希望在函数传入传出auto_ptr那么你可传递auto_ptr的引用,那就万无一失了: void fook(const auto_ptr<x>& m_PARAMin);在返回后赋予其它时,使用引用是不行的.你得用指针.因为引用无论作为lvalue还是rvaluev,都会调用构造或指派函数.

4.你是否觉得std::auto_ptr还不够完美

在实践中,std::auto_ptr能满足你的需求吗?           
Andrei Alexandrescu在一篇文章中,提及：有关Smart Pointer的技术就像巫术.Smart Pointer作为C++垃圾回收机制的核心,它必须足够强大的、具有工业强度和安全性.

但为了可一劳永逸我们还需要披荆斩棘继续探索.

下面在需求层面上,我们思索一下我们的智能指针还需要些什么?
a. std::auto_ptr 能够处理数组吗?我们可以用智能指针来管理其它的资源吗?譬如一个线程句柄、一个文件句柄 and so on !
b. 对于我们的对象真的永远实行独权政策吗?
c. Our 智能指针还需要在继承和虚拟层面上发挥威力 !
d. 往往,需要扩展Our 智能指针的功能成员函数来满足动态的需要 !
e. 也许,你需要的还很多.