std::智能指针

扫码查看

auto_ptr

用于解决资源自动释放问题,见如下代码:
void Function()
{
 Obj*p = new Obj(20);
 ...
 If (error occor)
  throw ... 或者 retrun;
 delete p;
}
在函数遇到错误之后,一般会抛异常,或者返回,但是这时可能泄露之前申请的资源,使用auto_ptr会在析够函数中进行资源释放。使用auto_ptr代码如下
void Function(){
  auto_ptr<Obj> ptr(new Obj(20));
  ...

  if (error occur)
   throw exception...
}
这样无论函数是否发生异常,在何处返回,资源都会被自动释放。
注:auto_ptr是被c++11标准废弃的一个智能指针,为什么会被废弃,见以下面代码:
auto_ptr<Obj> ptr1( new Obj() );
ptr1->FuncA();
auto_ptr<Obj> ptr2 = ptr1;
ptr2->FuncA();
ptr1->FuncA();  // 这句话会异常
为什么在将ptr1复制给ptr2之后ptr1使用导致异常?这正是它被抛弃的主因。因为auto_ptr复制构造函数中把真是引用内存指针进行了转移,就是从ptr1转移给ptr2,此后,ptr2引用了Obj内存地址,而ptr1引用内存地址为空,此时再使用ptr1则异常。

unique_ptr

unique_ptr作为auto_ptr替代品。它对引用对象所有权专一,因此得名unique
1) 无法进行复制构造和赋值操作
auto_ptr与unique_ptr的对比:
auto_ptr<Obj> ap(new Obj() );
auto_ptr<Obj> one (ap) ; // ok
auto_ptr<Obj> two = one; //ok

unique_ptr<Obj> ap(new Obj() );
unique_ptr<Obj> one (ap) ; //error

unique_ptr<Obj> two = one; //error

也就是unique_ptr对对象的引用专一,不允许随意转移。

2)  可进行移动构造和移动赋值操作
unique_ptr<Obj> GetObj()
{
  unique<Obj> ptr( new Obj() );
  return ptr;
}
unique<Obj> ptr = GetObj();
上面的代码可顺利执行!但万一需要将一个unique_ptr智能指针赋值给另外一个怎么办呢?可使用移动函数:什么是移动构造和移动赋值呢?(见C++11的标准规范)。
unique<Obj> ptr1(new Obj());
unique<Obj> ptr2(std::move(ptr1));
该效果与auto_ptr直接赋值一样,ptr1不再拥有Obj对象,之后ptr1不能再操作内存中Obj对象。 但因为移动操作为程序猿主动操作,因此程序员会留意使用。

shared_ptr

auto_ptr和unique_ptr只能用一个智能指针引用对象,而shared_ptr则是可以多个智能指针同时拥有一个对象。shared_ptr实现方式是采用引用计数。引用计数原理即多个智能指针同时引用一个对象,每当引用一次,引用计数加1,当一个智能指针销毁,引用计数减1,当引用计数减少到0的时释放引用对象。这种引用计数增减发生在智能指针的构造函数,复制构造函数,赋值操作符,析构函数中。这种方式使得多个智能指针同时对所引用的对象有拥有权,同时在引用计数减到0之后自动释放资源,也实现了auto_ptr和unique_ptr的资源释放功能。
void Function()
 {
  shared_ptr<Obj> ptr1(new Obj() ); // 引用计数为1
  {
   shared_ptr<Obj> ptr2(ptr1); // 引用计数为2
   {
     shared_ptr<Obj> ptr3 = ptr2; // 引用计数为3
     int e = 0;

   }
   //引用计数为2
  }
  //引用计数为1
}
//函数返回之后引用计数为0,new 出来的Obj内存被释放。

由于shared_ptr支持复制构造,所以它可作为标准库容器中的元素
vector<shared_ptr<Obj>> vect;
for (int i = 0; i < 10; ++i){
  vect.push_back( shared_ptr<Obj>( new Obj() ) );
}
vector<shared_ptr<Obj>> vect2 = vect;
这些操作是auto_ptr和unique_ptr不能实现的。注意,智能指针默认使用delete来释放资源,如果资源是FILE*怎么办?释放的时候就需要用fclose了。如何实现呢? 
shared_ptr构造函数可以传递一个删除器。
FILE* pStm = fopen(...);
shared_ptr<FILE> fileRes(pStm, &fclose);
或者使用一个仿函数
class FileCloser { 
     public: 
        void operator()(FILE* file) { 
         std::cout << "The FileCloser has been called with a FILE*, " 
           "which will now be closed.\n"; 
         if (file!=0)  
           fclose(file); 
       } 
     }; 
shared_ptr<FILE> fileRes(pStm, FileCloser);

weak_ptr

shared_ptr是一种强引用的关系,智能指针直接引用对象。那么这个代码有一个隐含的问题,就是循环引用,从而造成内存泄漏。示例看一个循环引用的例子。
class Parent{
public:
    shared_ptr<Child> child;
};
class Child{
public:
    shared_ptr<Parent> parent;
};
void Function() {
  shared_ptr<Parent> pA(new Parent);
  shared_ptr<Child> pB(new Child);
  pA->child = pB;
  pB->parent = pA;
}
现在来分析一下Function函数的执行过程:
1. 第一条语句使得pA引用了Parent一个指针,Parent引用计数为1
2. 第二条语句使得pB引用了Child一个指针,Child引用计数为1
3. 第三条语句,调用了shared_ptr<Child>类赋值操作符,使得Child引用计数变为2
4. 第四条语句,调用了shared_ptr<Parent>类赋值操作符,使得Parent引用计数变为2
5. 函数返回之前调用了shared_ptr<Parent>和shared_ptr<Child>类的析够函数,使得Child引用计数变为1,Parent引用计数变为1
看!函数执行完之后new出来的Parent和Child并没有释放,所以出现了内存泄漏。
出现泄漏的原因就是pA和pB相互引用了,导致两者所引用对象的引用计数不能减少到0,造成泄漏。
如果把第三条语句或者第四条语句任意删除一个,则不会泄漏了。这就是强引用所致问题。
weak_ptr字面意思即一个弱指针,并不指该指针能力弱,而是指对它所引用对象所有权弱,它并不拥有所引用对象所有权,且不能直接使用所引用对象。在stl中,weak_ptr是和shared_ptr配合使用的,在实现shared_ptr的时候也就考虑了weak_ptr的因素。
weak_ptr是shared_ptr的观察者,它不会干扰shared_ptr所共享对象的所有权,
当一个weak_ptr所观察的shared_ptr要释放它的资源时,它会把相关的weak_ptr的指针设置为空,防止weak_ptr持有悬空的指针。
注意:weak_ptr并不拥有资源的所有权,所以不能直接使用资源。
可以从一个weak_ptr构造一个shared_ptr以取得共享资源的所有权。
void Function()
{
 shared_ptr<int> sp( new Obj() );
 assert(sp.use_count() == 1);
 weak_ptr<int> wp(sp); //从shared_ptr创建weak_ptr
 assert(wp.use_count() == 1);
 if (!wp.expired())//判断weak_ptr观察的对象是否失效
 {
  shared_ptr<int> sp2 = wp.lock();//获得一个shared_ptr
  *sp2 = 100;
  assert(wp.use_count() == 2);
 }
 assert(wp.use_count() == 1);
 return 0;
}
weak_ptr并没有重载-> 和 * 操作符,所以我们不能通过他来直接使用资源,我们可以通过lock来获得一个shared_ptr对象来对资源进行使用,如果引用的资源已经释放,lock()函数将返回一个存储空指针的shared_ptr。 expired函数用来判断资源是否失效。使用weak_ptr并不会增加资源的引用计数。所以对资源的引用是弱引用,利用这个特性可以解决前面所说的循环依赖问题。

class Parent {
public:
    weak_ptr<Child> child;
};
class Child {
public:
    weak_ptr<Parent> parent;
};
void Function()
{
 shared_ptr<Parent> pA(new Parent);
 shared_ptr<Child> pB(new Child);
 pA->child = pB;
 pB->parent = pA;
}
此时第三和第四条语句的执行并没有增加引用计数,从而在函数执行完成只有能自动释放内存。以上分析可见,weak_ptr是一种辅助shared_ptr的智能指针,一般不单独使用,而是结合shared_ptr一起使用。

应用总结

尽量使用unique_ptr而不是auto_ptr

shared_ptr满足大部分需求;

weak_ptr避免递归的依赖关系;

make_shared

1. 在初始化unique_ptr或者shared_ptr时,优先使用std::make_unique和std::make_shared。原因:

1)异常安全性

假设有如下函数声明:

intcomputePriority();
void processInvestment(std::shared_ptr<Investment> ptr,int priority);
调用processInvestment的代码如下所示:

processInvestment(std::shared_ptr<Investment>(newInvestment()),computePriority());

由于在C++中函数参数的执行顺序不固定,所以在上面对函数processInvestment调用中,函数参数的执行顺序很可能是:

 new Investment

 computePriority()

 std::shared_ptr constructor

这种执行顺序的风险是,如果在第二步,执行computePriority的过程中出现异常,那么在第一步中new出来的对象将变得不可访问,从而造成内存泄漏。
通过make_ptr的方式,将new操作和shared_ptr的构造放在一起执行,就不会出现内存泄漏问题了。

2)执行效率(对于shared_ptr而言)

std::shared_ptr<Investment>ptr(new Investment); //方式1,new的方式在方式1中,会涉及到两次动态内存分配:

第1次是new Investment时,为Investment对象分配空间; 第2次是为控制块(Control Block)分配空间。

auto pIn = std::make_shared<Investment>();//方式2,make_shared的方式

在方式二中,一次动态内存分配就足够了,这是由于make_shared会为Investment对象和控制块(Control block)一次性分配一大块内存。由于只有一次内存分配,因而方式二提高了程序的执行效率。

2、make_xxx函数的弊端

既然使用make_xxx有这么多好处,是否应处处使用make函数而完全放弃new方式?当然不是,make函数存在以下限制:

1) make函数不支持用户自定义释放器。由于make函数有自己的内存分配和析构规则,所以不适用于自定义分配器和释放器的对象。

2) make函数不支持大括号初始化方式。对于下面这句代码:

auto spv = std::make_shared<vector<int>>(10,20);

意为spv指向一个vector,该vector有10个元素,每个元素值为20。如果想实现的是这个vector有两个元素,分别为10,20的话,只能用new方式。

3) 内存释放不够灵活。

在使用new的方式中,有两块独立的堆内存,一块存放资源对象,一块存放控制块,当资源对象的引用计数为0的时候,资源对象会被销毁,它所占用的内存也会被随之销毁。

在使用make函数的方式中,make函数一次性为资源对象和控制块分配了一块内存,当资源对象的引用计数为0是,对象被销毁,但是资源对象占用的内存却不会被销毁,只有当控制块占用的内存被销毁是才会将资源对象所占内存一并释放。那么,控制块内存什么时候被释放呢?这就涉及到控制块中另一个引用计数了,这个引用计数被称为“Weak Count”,其作用是用来计数指向该资源的weak_ptr的数量。当这个weak count的值为0时,控制块才会被释放。当资源对象非常庞大时,使用make函数的方式将造成不小的资源浪费。

   
08-29 07:26
查看更多