智能指针std::auto_ptr和tr1:shared_ptr用法

下面通过一个工厂函数(createInvestment())返回一个特定的investment对象:

Investment* createInvestment();

 

见如下函数:

void f()

{

    Investment* pInv = createInvestment();

    ....

    delete pInv;

}

上面的程序会有以下危险:

1>...区域内的一个过早的return语句,控制流将不会触及delete语句

2>或createInvestment()和delete动作位于某循环内,该循环由于某个continue或goto语句过早退出.

3>...区域内的语句抛出异常,控制流也不会触及delete

无论delete如何被略过去,我们泄漏的不只是内含investment对象的那块内存,还包括那些investment对象所保存的任何资源.

 

为确保createInvestment()返回的资源总是被释放,我们需要将资源放进对象内,当控制流离开f,该对象的析构函数会自动释放那些资源,(RAII)如下:

void f()

{

    std::auto_ptr<Investment> pInv(createInvestment());

    ....

}

 

由于auto_ptr被销毁时会自动删除它所指之物,所以一定要注意别让多个auto_ptr同时指向同一对象,如果真是这样,对象会被删除一次以上,而那会使你的程序搭上驶向"未定义行为"的快速列车上,为了预防这个问题,auto_ptr有一个不同寻常的性质,若通过copy构造函数或copy
assignment操作符复制它们,它们会变成null,而复制所得的指针将取得资源的唯一拥有权!如下:

std::auto_ptr<Investment> pInv1(createInvesment());//pInv1指向createInvesment()返回物

std::auto_ptr<Investment> pInv2(pInv1);            //现在pInv2指向对象,pInv1被设为null

pInv1 = pInv2;                                     //现在pInv1指向对象,pInv2被设为null

 

但是auto_ptr并非管理动态分配资源的神兵利器, STL容器要求其元素发挥"正常的"复制行为, 因此这些容器容不得auto_ptr

 

针对以上的问题auto_ptr的替代方案是RCSP,其也是个智能指针, RCSP提供类似垃圾回收行为,但其无法打破环状引用:TR1的tr1::shared_ptr就是个RCSP,可以如下写f函数:

void f()

{

   ...

   std::tr1::shared_ptr<Investment> pInv(createInvesment());

   ...

}

上段代码看起来与auto_ptr的那个版本相同,但他的复制行为就正常多了,如下:

void f()

{

   ...

   std::tr1::shared_ptr<Investment> pInv1(createInvestment());//pInv1指向createInvesment返回物

   std::tr1::shared_ptr<Investment> pInv2(pInv1);             //pInv1和pInv2指向同一个对象

   pInv1 = pInv2;                                             //同上

   ...                            //pInv1和pInv2被销毁,它们所指的对象也就被自动销毁

}

 

由于tr1::shared_ptr的复制行为"一如预期",它们可被利用于STL容器以及其它的"auto_ptr之非正统复制行为并不适用"的语镜上,以上即使使用了智能指针,最佳仍需要对createInvestment进行接口修改.

 

总结如下:

1>为防止资源,请使用RAII对象,它们在构造函数中获得资源并在析构函数中释放资源

2>两个经常被使用的RAII类分别是tr1::shared_ptr和auto_ptr,前者通常是较佳选择,因为其copy行为比较直观,若选择auto_ptr,复制动作会使被复制物指向null