编程语言

img haoel

标准C++类string的Copy-On-Write技术(三)

发表于2004/6/23 16:15:00  15534人阅读

分类: 编程语言

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

 

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

 

string h1 = “hello”;

string h2= h1;

string h3;

h3 = h2;

 

string w1 = “world”;

string w2(“”);

w2=w1;

 

很明显,我们要让h1h2h3共享同一块内存,让w1w2共享同一块内存。因为,在h1h2h3中,我们要维护一个引用计数,在w1w2中我们又要维护一个引用计数。

 

如何使用一个巧妙的方法产生这两个引用计数呢?我们想到了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;
         }
 

}

 

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

 

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

 

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

 

 

2.4、         臭虫Bug

 

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

 

不信?!那么让我们来看一个测试案例:

 

假设有一个动态链接库(叫myNet.dllmyNet.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();

 

 

3、             后记

 

文章到这里也应该结束了,这篇文章的主要有以下几个目的:

 

1)    向大家介绍一下写时才拷贝/内存共享这种技术。

2)    STL中的string类为例,向大家介绍了一种设计模式。

3)    C++世界中,无论你的设计怎么精巧,代码怎么稳固,都难以照顾到所有的情况。智能指针更是一个典型的例子,无论你怎么设计,都会有非常严重的BUG

4)    C++是一把双刃剑,只有了解了原理,你才能更好的使用C++。否则,必将引火烧身。如果你在设计和使用类库时有一种“玩C++就像玩火,必须千万小心”的感觉,那么你就入门了,等你能把这股“火”控制的得心应手时,那才是学成了。

 

最后,还是利用这个后序,介绍一下自己。我目前从事于所有Unix平台下的软件研发,主要是做系统级的产品软件研发,对于下一代的计算机革命——网格计算非常地感兴趣,同于对于分布式计算、P2PWeb ServiceJ2EE技术方向也很感兴趣,另外,对于项目实施、团队管理、项目管理也小有心得,希望同样和我战斗在“技术和管理并重”的阵线上的年轻一代,能够和我多多地交流。我的MSN和邮件是:haoel@hotmail.com

 

我的专栏是:

http://blog.csdn.net/haoel/

 

 

<-上一页

(版权所有,转载时请注明作者和出处)

阅读全文
0 0

相关文章推荐

img
取 消
img