标准C＋＋类string的Copy-On-Write技术(3)

最新推荐文章于 2023-11-29 17:54:02 发布

zhongjiekangping

最新推荐文章于 2023-11-29 17:54:02 发布

阅读量1k

点赞数

分类专栏： C++ 文章标签： string c crash 设计模式扩展 basic

C++ 专栏收录该内容

77 篇文章 0 订阅

订阅专栏

2.3.4、 Copy-On-Write的具体实现是怎么样的？

最后的这个问题，我们主要解决的是那个“民主集中”的难题。请先看下面的代码：

string h1 = “hello”;

string h2= h1;

string h3;

h3 = h2;

string w1 = “world”;

string w2(“”);

w2=w1;

很明显，我们要让h1、h2、h3共享同一块内存，让w1、w2共享同一块内存。因为，在h1、h2、h3中，我们要维护一个引用计数，在w1、w2中我们又要维护一个引用计数。

如何使用一个巧妙的方法产生这两个引用计数呢？我们想到了string类的内存是在堆上动态分配的，既然共享内存的各个类指向的是同一个内存区，我们为什么不在这块区上多分配一点空间来存放这个引用计数呢？这样一来，所有共享一块内存区的类都有同样的一个引用计数，而这个变量的地址既然是在共享区上的，那么所有共享这块内存的类都可以访问到，也就知道这块内存的引用者有多少了。

请看下图：

于是，有了这样一个机制，每当我们为string分配内存时，我们总是要多分配一个空间用来存放这个引用计数的值，只要发生拷贝构造可是赋值时，这个内存的值就会加一。而在内容修改时，string类为查看这个引用计数是否为0，如果不为零，表示有人在共享这块内存，那么自己需要先做一份拷贝，然后把引用计数减去一，再把数据拷贝过来。下面的几个程序片段说明了这两个动作：

//构造函数（分存内存）

string::string(const char* tmp)

{

_Len = strlen(tmp);

_Ptr = new char[_Len+1+1];

strcpy( _Ptr, tmp );

_Ptr[_Len+1]=0; // 设置引用计数

}

//拷贝构造（共享内存）

string::string(const string& str)

{

if (*this != str){

this->_Ptr = str.c_str(); //共享内存

this->_Len = str.szie();

this->_Ptr[_Len+1] ++; //引用计数加一

}

//写时才拷贝Copy-On-Write

char& string::operator[](unsigned int idx)

{

if (idx > _Len || _Ptr == 0 ) {

static char nullchar = 0;

return nullchar;

}

_Ptr[_Len+1]--; //引用计数减一

char* tmp = new char[_Len+1+1];

strncpy( tmp, _Ptr, _Len+1);

_Ptr = tmp;

_Ptr[_Len+1]=0; // 设置新的共享内存的引用计数

return _Ptr[idx];

}

//析构函数的一些处理

~string()

{

_Ptr[_Len+1]--; //引用计数减一

// 引用计数为0时，释放内存

if (_Ptr[_Len+1]==0) {

delete[] _Ptr;
}

}

哈哈，整个技术细节完全浮出水面。

不过，这和STL中basic_string的实现细节还有一点点差别，在你打开STL的源码时，你会发现其取引用计数是通过这样的访问：_Ptr[-1]，标准库中，把这个引用计数的内存分配在了前面（我给出来的代码是把引用计数分配以了后面，这很不好），分配在前的好处是当string的长度扩展时，只需要在后面扩展其内存，而不需要移动引用计数的内存存放位置，这又节省了一点时间。

STL中的string的内存结构就像我前面画的那个图一样，_Ptr指着是数据区，而RefCnt则在_Ptr-1 或是 _Ptr[-1]处。

2.4、臭虫Bug

是谁说的“有太阳的地方就会有黑暗”？或许我们中的许多人都很迷信标准的东西，认为其是久经考验，不可能出错的。呵呵，千万不要有这种迷信，因为任何设计再好，编码再好的代码在某一特定的情况下都会有Bug，STL同样如此，string类的这个共享内存/写时才拷贝技术也不例外，而且这个Bug或许还会让你的整个程序crash掉！

不信？！那么让我们来看一个测试案例：

假设有一个动态链接库（叫myNet.dll或myNet.so）中有这样一个函数返回的是string类：

string GetIPAddress(string hostname)

{

static string ip;

……

return ip;

}

而你的主程序中动态地载入这个动态链接库，并调用其中的这个函数：

main()

{

//载入动态链接库中的函数

hDll = LoadLibraray(…..);

pFun = GetModule(hDll, “GetIPAddress”);

//调用动态链接库中的函数

string ip = (*pFun)(“host1”);

……

//释放动态链接库

FreeLibrary(hDll);

……

cout << ip << endl;

}

让我们来看看这段代码，程序以动态方式载入动态链接库中的函数，然后以函数指针的方式调用动态链接库中的函数，并把返回值放在一个string类中，然后释放了这个动态链接库。释放后，输入ip的内容。

根据函数的定义，我们知道函数是“值返回”的，所以，函数返回时，一定会调用拷贝构造函数，又根据string类的内存共享机制，在主程序中变量ip是和函数内部的那个静态string变量共享内存（这块内存区是在动态链接库的地址空间的）。而我们假设在整个主程序中都没有对ip的值进行修改过。那么在当主程序释放了动态链接库后，那个共享的内存区也随之释放。所以，以后对ip的访问，必然做造成内存地址访问非法，造成程序crash。即使你在以后没有使用到ip这个变量，那么在主程序退出时也会发生内存访问异常，因为程序退出时，ip会析构，在析构时就会发生内存访问异常。

内存访问异常，意味着两件事：1）无论你的程序再漂亮，都会因为这个错误变得暗淡无光，你的声誉也会因为这个错误受到损失。2）未来的一段时间，你会被这个系统级错误所煎熬（在C++世界中，找到并排除这种内存错误并不是一件容易的事情）。这是C/C++程序员永远的心头之痛，千里之堤，溃于蚁穴。而如果你不清楚string类的这种特征，在成千上万行代码中找这样一个内存异常，简直就是一场噩梦。

备注：要改正上述的Bug，有很多种方法，这里提供一种仅供参考：

string ip = (*pFun)(“host1”).cstr();