最后的這個問題，我們主要解決的是那個“民主集中”的難題。請先看下面的代碼：
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];
}       
      哈哈，整個技術細節完全浮出水面。
      不過，這和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();

3、后記
      文章到這里也應該結束了，這篇文章的主要有以下幾個目的：
1） 向大家介紹一下寫時才拷貝/內存共享這種技術。
2） 以STL中的string類為例，向大家介紹了一種設計模式。
3） 在C++世界中，無論你的設計怎么精巧，代碼怎么穩固，都難以照顧到所有的情況。智能指針更是一個典型的例子，無論你怎么設計，都會有非常嚴重的BUG。
4） C++是一把雙刃劍，只有了解了原理，你才能更好的使用C++。否則，必將引火燒身。如果你在設計和使用類庫時有一種“玩C++就像玩火，必須千萬小心”的感覺，那么你就入門了，等你能把這股“火”控制的得心應手時，那才是學成了。