第三章资源管理

最新推荐文章于 2024-01-12 09:15:00 发布

五山小新新

最新推荐文章于 2024-01-12 09:15:00 发布

阅读量456

点赞数

分类专栏： Effective C++

本文链接：https://blog.csdn.net/Al_xin/article/details/38427217

版权

Effective C++ 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

所谓资源就是，一旦用了它，将来必须还给系统。如果不这样，糟糕的事情就会发生。C++程序中最常见使用的资源就是动态分配内存，导致的内存泄漏，但内存只是你必须管理的众多资源之一。其他常见的资源还包括文件描述器（file descriptors）、互斥锁（mutex locks）、图形界面中的字型和笔刷、数据库连接、以及网络sockets.不论哪一种资源，重要的是，当你不再使用它时，必须还给系统。

条款13 以对象管理资源

许多资源被动态分配与heap内而后被用于单一区块或函数内，他们应该在控制流离开那个区块或者函数时被释放。标准库通的auto_ptr正是针对这种形势特制的。auto_ptr是个“类指针对象”，也就是所谓的智能指针，其析构函数自动对其所指对象调用delete。用法如下：

    C++ Code  
 

1
2
3
4
5

void f()
{
std::auto_ptr<Investment> pInv(createInvestment());
//调用工厂函数，一如既往的使用pInv，经由auto_ptr的析构函数自动删除pInv
}

根据上面的例子，我们对“以对象管理资源”的两个关键想法。

获得资源后立刻放进管理对象内。（RAII：资源获取实际便是初始化时机）

管理对象运行析构函数确保资源被释放。

上面给出了auto_ptr的智能指针有个问题就是，一定不能让多个auto_ptr同时指向同一个对象，原因在于auto_ptrs有一个不寻常的性质：若通过copy构造函数或copy assignment操作符复制它们，它们会变成null，而复制所得的指针将获得资源的唯一拥有权，见如下代码：

    C++ Code  
 

1
2
3
4
5
6

std::auto_ptr<Investment> pInv1(createInvestment());
//pInv1指向createInvestment返回对象
std::auto_ptr<Investment> pInv2(pInv1);
//pInv2指向createInvestment返回对象 ,pInv1为NULL
pInv1=pInv2;
//pInv1指向createInvestment返回对象,pInv2为NULL

解决方案二：

auto_ptr的替代方案是“引用计数智慧指针（RCSP）”，所谓的RCSPs也是智能指针，持续跟踪共有多少个对象指向某笔资源，并在无人指向它时自动删除该资源。RCSPs提供的行为类似垃圾回收，不同的是RCSPs无法打破环状引用，具体用法如下所示

    C++ Code  
 

1
2
3
4
5
6
7
8
9
10
11
12

void f()
{
    std::tr1::shared_ptr<Investment> pInv1(createInvestment());
     //pInv1指向createInvestment返回对象
    std::tr1::shared_ptr<Investment> pInv2(pInv1);
     //pInv2和pInv1同一个对象
    pInv1 = pInv2;
     //同上
    ...
     //pInv2和pInv1b被销毁
     //他们所指的对象同样被销毁
}

不适用情况：

auto_ptr和tr1::shared_ptr两者都在其析构函数内做delete而不是delete[]动作，因此动态分配而得到的array身上适用这两个智能指针是个坏主意。

    C++ Code  
 

1
2

std::auto_ptr<std::string> aps( new std::string[ 10]); //坏主意，能编译
std::tr1::shared_ptr< int> spi( new int[ 1024]); //相同问题

请记住：

为了防止资源泄漏，请使用RAII对象，它们在构造函数中获得资源并在析构函数中释放资源。

两个常用的RAII分别是tr1::shared_ptr和auto_ptr。前者通常是较佳的选择，因为其copy行为比较直观。若选择auto_ptr，复制它动作是它指向null。

条款14 在资源管理类中小心copying行为

有时候，我们需要自己建立资源管理类，在这个时候，我们需要特别小心copying行为。如下例子：

     C++ Code  
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Lock
{
public:
     explicit Lock(Mutex *pm):mutexPtr(pm)
    {
     lock(mutexPtr); //获得资源
    }
    ~Lock()
    {
     unlock(mutexPtr);   //释放资源
    }
private:
    Mutex *mutexPtr;
}
//定义互斥器
Mutex m;
...              //建立一个区块用来定义critical section
Lock m1(&m);     //锁定互斥器
...              //执行critical section 内的操作、在区块最末尾，自动解除互斥器锁定

///如果Lock对象被复制，会发生什么呢?
Lock m11(&m); //锁定m
Lock m12(m11);   //复制

这种复制行为会为程序带来不确定性。因为我们在进行copying行为时，应该要有以下四重考虑：

1、许多时候允许RAII对象被复制并不合理。对一个像Lock这样的类这是可能的，因为很少能够合理拥有“同步化基础物”的副本。如果复制对RAII并不合理，你应该禁止复制。条款6告诉我们怎么做：将copying操作声明为private，对Lock而言看起来是这样的：

     C++ Code  
  

1
2
3
4
5

class Lock : private Uncopyable //禁止复制
{
public:
...
};

2、有时候我们希望保持资源，直到它最后一个使用者被销毁，这种情况下复制RAII对象时，应该将资源的“被引用数”递增，trl::shared_ptr便是如此。

通常只要内含一个tr1::shared_ptr成员变量，RAII类便可实现出引用计数行为。如果前述Lock打算使用使用技术，它可以改变mutexPtr类型，将它从Mutex*改为tr1::shared_ptr<Mutex>。然而不幸tr1::shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，那不是我们所要的行为。幸运的是tr1::shared_ptr允许指定所谓的“删除器”，那是一个函数或函数对象，当引用次数为0时便调用。删除器对tr1::shared_ptr构造函数而言是可有可无的第二参数，所以代码看起来像这样：

     C++ Code  
  

1
2
3
4
5
6
7
8
9
10
11

class Lock
{
public:
     explicit Lock(Mutex *pm) //以某个Mutex初始化shard_ptr并以unlock函数
        : mutexPtr(pm, unlock) //为删除器
    {
        lock(mutexPtr.get()); //条款15谈到 get
    }
private:
    std::tr1::shared_ptr<Mutex> mutexPtr; //使用shared_ptr
};

本例的Lock不再声明析构函数，因为没有必要。条款5说过，类的析构函数会自动调用其non_static成员变量的析构函数。而mutexPtr的析构函数会在互斥器的引用次数为0的时候自动调用tr1::shared_ptr的删除器。

3.复制底层资源

有时候只要你喜欢，可以针对一份资源拥有其任意数量的副件，而你需要“资源管理类”的唯一理由是，当你不再需要某个副本的时候确保它被释放，在此情况下复制资源管理对象，应该同时也复制其所包覆的资源，也就是说，复制资源管理了对象时，进行的是“深度拷贝”。

4.转移底部资源的拥有权

某些罕见场合下你可能希望确保永远只有一个RAII对象指向一个未加工资源，即使RAII对象被复制依然如此。此时资源的拥有权会从被复制物转移到目标物。如条款13所诉。这是atuo_ptr奉行的复制意义。

copying函数有可能被编译器自动创建出来，因而除非编译器所生成版本做了你想要做的事情，否则你的自己编写它们。某些情况下你或许也想支持这些函数版本，这样的版本描述于条款45

请记住：

复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为。

普通而常见的RAII类copying行为是：抑制copying，施行引用计数法，不过其他行为都可能被实现。

条款15 在资源管理类中提供对原始资源的访问

1.如何访问原始资源

在上两条款我们知道如何使用智能指针管理我们的申请的资源，但是读者是否发现，我们如何去访问我们原始资源的方法呢？在这一条款将得到解答以及类型转换的相关问题。

首先，我们用代码来说话吧，及输出的结构看到

      C++ Code  
   

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// pro_acce.cpp : 定义控制台应用程序的入口点。
//2011/9/21  by wallwind on sunrise;
#include "stdafx.h"
#include <iostream>
#include <memory>
using namespace std;
class myClass
{
public :
    myClass()
    {
        cout<< "myClass()"<<endl;
    }
    ~myClass()
    {
        cout<< "~myClass()"<<endl;
    }
     void printFunc()
    {
        cout<< "printFunc()"<<endl;
    }
int getType() const
    {
         return type;
    }
private:
     int type;
};
myClass* creatMyClass()
{
    myClass *my= new myClass();
     return my;
}
void issue(myClass *my) {
     delete my;
}
int _tmain( int argc, _TCHAR* argv[])
{
    auto_ptr<myClass> apMy(creatMyClass());
    myClass* myC=apMy.get(); //auto_ptr 给我们提供的函数，用来访问原始资源
    myC->printFunc(); //调用了myClass的方法
     return 0;
}

从这里我们可以看到，程序输出了我们想要的结果。如书中所述：

tr1::shared_ptr 和 auto_ptr 都提供了一个 get 成员函数来进行显式转换，也就是说，返回一个智能指针对象中的裸指针（的副本）：

myClass* myC=apMy.get();//

似乎所有的智能指针类，包括 tr1::shared_ptr 和 auto_ptr 等等，都会重载指针解析运算符（ operator-> 和 operator* ），这便使得对原始裸指针进行隐式转换成为现实，在这里我就不实际举例子了。下面使用书中的片段代码来说明一下问题吧：

     C++ Code  
  

1
2
3
4
5
6
7
8
9
10
11

std::tr1::shared_ptr<Investment> pi1(createInvestment());
// 使用 tr1::shared_ptr
// 管理资源
bool taxable1 = !(pi1->isTaxFree());
// 通过 operator-> 访问资源
...
std::auto_ptr<Investment> pi2(createInvestment());
// 使用 auto_ptr 管理资源
bool taxable2 = !((*pi2).isTaxFree());
// 通过 operator* 访问资源

出色的资源管理类型可以避免资源泄露并有效的管理资源，但世界并非是如你所愿的。当某个API需要使用资源管理类型把持的原始资源时，这样的麻烦又会随之而来。

也许您注意到了

     C++ Code  
  

1
2
3
4
5
6
7
8
9
10
11
12

void issue(myClass *my)
        {
         delete my;
        }
//这个函数没有使用到，那么当你使用这个时候
int _tmain( int argc, _TCHAR* argv[])
{
    auto_ptr<myClass> apMy(creatMyClass());
    issue(apMy.get());
     return 0;
}

就出现了问题。结果大家可以试一下。

2.隐式转换

因为有时候要取得RAII对象内原始资源， RAII设计者使用了一种隐式转换函数，

如果让资源管理类型提供隐式转换函数，可以让行为变的更自然，但这样的作法没有好下场，只会增加客户端发生错误的机率。比如下面的代码（简单的编写了一个自定义的AutoPtr，它重载了隐式转换operator）：

     C++ Code  
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

#include "stdafx.h"
#include <stdlib.h>
#include <memory>
#include <string>
using namespace std;

template< typename T>
class AutoPtr
{
public:
    AutoPtr(T *tP)
        : _tP(tP), _released( false) { }
    ~AutoPtr()
    {
        Release();
    }
    T * operator->()
    {
         return _tP;
    }
     operator T *() const
    {
         return _tP;
    }
     void Release( void)
    {
         if (!_released)
        {
             delete _tP;
            _released = true;
        }
    }
private:
    T *_tP;
     bool _released;
};

typedef struct Point
{
     double X;
     double Y;
};

void PrintPoint(Point *pTP) { }

int _tmain( int argc, _TCHAR *argv[])
{
    AutoPtr<Point> apI( new Point());
    PrintPoint(apI);
    Point *pTP = apI;
    apI.Release();
    system( "pause");
     return 0;
}

pTP也获得了apI提供的Point指针，当apI作用域结束后或显示调用了Release方法，pTP也就成了迷途指针了。通常来说提供Get方法是比较大众切容易接受的正确方法，它将隐式转换所带来的恶意最小化。
也许在诸如auto_ptr、shared_ptr只提供原始指针的访问违背了面向对象的封装性，可能是令人产生误解和迷惑的地方。因为RAII classes并不是为了封装某物而存在的，更多的它只是一种模版编程的概念。

     C++ Code  
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

#include "stdafx.h"

#include <stdlib.h>

#include <memory>

#include <string>

using namespace std;

template< typename T>

class AutoPtr
{

public:

    AutoPtr(T *tP)

        : _tP(tP), _released( false) { }

    ~AutoPtr()
    {

        Release();

    }

    T * operator->()
    {

         return _tP;

    }

     operator T *() const
    {

         return _tP;

    }

     void Release( void)
    {

         if (!_released)
        {

             delete _tP;

            _released = true;

        }

    }

private:

    T *_tP;

     bool _released;

};

typedef struct Point
{

     double X;

     double Y;

};

void PrintPoint(Point *pTP) { }

int _tmain( int argc, _TCHAR *argv[])
{

    AutoPtr<Point> apI( new Point());

    PrintPoint(apI);

    Point *pTP = apI;

    apI.Release();

    system( "pause");

     return 0;

}

牢记在心

l API 通常需要访问原始资源，因此每个 RAII 类都应该提供一个途径来获取它所管理的资源。

l 访问可以通过显式转换或隐式转换来实现。一般情况下，显式转换更安全，但是隐式转换对于客户端程序员来说使用更方便。

条款16 成对使用new和delete时要采用相同形式

原理还是：使用new，配对使用delete，使用new[]，配对使用delete[] 。但是使用new[]时，采用delete呢？会导致析构函数少调用情况。

要有就是尽量少使用数组。因为C++标准库含有string、vector等template，可将数组的需求降至几乎为0.

条款17 以独立语句将newed对象置入智能指针

c++编译器会优化你的代码，会根据优先权来选择优先执行哪些代码。C++编译器以什么样的此讯完成这些事情呢？弹性很大。这和其他诸如java，c#不同。她们总是以特定顺序来执行。

      C++ Code  
   

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// store_new.cpp : 定义控制台应用程序的入口点。

#include "stdafx.h"
#include <iostream>
#include <memory>
using namespace std;
class Widget
{
public:
    Widget()
    {
        cout << "Widget()" << endl;
    }
    ~Widget()
    {
        cout << "Widget()" << endl;
    }
};
int priority()
{
     throw new runtime_error( "Exception");
     //return 0;
}
void processWidger(auto_ptr<Widget> pw, int priority) {}

int _tmain( int argc, _TCHAR *argv[])
{
    processWidger(auto_ptr<Widget>( new Widget()), priority());
    system( "pause");
     return 0;
}

Priority函数返回一个执行的优先级， processWidger 函数则根据优先级来处理某个类型的对象（许多程序员有时候愿意将某个函数直接做为参数传递进另个函数内）。
1、调用X的构造函数。
2、调用auto_ptr< Widget >的构造函数。
3、调用Priority函数。
看上去井然有序的条件，C++编译器未必会选择这么做。也许编译器选择将调用Priority函数放在第二的位置会生成更高效的代码也说不定。那么顺序就会改为：
1、调用X的构造函数。
2、调用Priority函数。
3、调用auto_ptr< Widget >的构造函数。
那么如果调用Priority函数产生异常怎么办？auto_ptr并没有获得它需要保管的资源，而那段资源也不会遭到释放，有一种资源泄漏的方式。
解决方式就是在外面完成智能指针的存储，编译器对于跨越语句的各项操作不会选择重新排列。这样智能指针依然获得了对所指向资源的保护。

      C++ Code  
   

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// store_new.cpp : 定义控制台应用程序的入口点。
#include "stdafx.h"
#include <iostream>
#include <memory>
using namespace std;
class Widget
{
public:
    Widget()
    {
        cout << "Widget()" << endl;
    }
    ~Widget()
    {
        cout << "Widget()" << endl;
    }
};
int priority()
{
     throw new runtime_error( "Exception");
     //return 0;
}
void processWidger(auto_ptr<Widget> pw, int priority) {}
int _tmain( int argc, _TCHAR *argv[])
{
    auto_ptr<Widget> pw( new Widget());
    processWidger(pw, priority());
    system( "pause");
     return 0;
}

由于编译器对"跨越语句块的各项操作"失去了执行重新排列的自由,所以编译器不能在它们之间任意选择执行顺序.

请记住:
■ 以独立语句将newed对象存储于(置入)智能指针内.如果不这样做,一旦异常被抛出,有可能导致难以察觉的资源
泄露.