[轉]C++ 之 stl::string 寫時拷貝導致的問題

前幾天在開發某些資料結構到檔案的 Dump 和 Load 功能的時候， 遇到的一個 bug 。

問題復現###

問題主要出在 Load 過程中，從檔案讀取資料的時候， 直接使用 fread 的去操作 string 的內部指標地址 (char)s.c_str() 。 簡化後的示例程式碼如下（testdata1檔案內容是12345)
<pre>
void Load(string& s, size_t offset, size_t size) {
s.resize(size);
FILE fp = fopen("testdata1", "r");
assert(fp != NULL);
fseek(fp, offset, SEEK_SET);
fread((char*)s.c_str(), sizeof(char), size, fp);
fclose(fp);
}
</pre>

通過 string::resize() 分配記憶體空間。 通過 string::c_str() 直接獲取記憶體空間的起始地址並寫入資料。

這樣的用法是典型的使用 string 當資料緩衝區的用法， 省去了 malloc(new) 和 free(delete) 的過程。 通常來講不會遇到什麼問題。

不過這次遇到問題了。

簡化問題程式碼示例如下：
<pre>
string s;
Load(s, 0, 3);
assert(s == "123"); // success

string s2 = s;
Load(s2, 1, 3);
assert(s2 == "234"); // success
assert(s == "123"); // failed
</pre>

注: 因為 testdata1 檔案內容是 12345 的純文字檔案。 所以 Load(s, 0, 3) 內容就是 “123” ，依此類推。

但是當後面的 string s2 = s; 定義了一個和 string 變數 s2 。 此時 Load(s2, 1, 3); 時 s2 內容是 “234” 符合預期。

但是問題出在之後 s 的內容也變成了 “234” ， 而不是保持原來的 “123” 。

原因分析###

其實示例程式碼寫成那樣，問題也清楚了很多了， 問題就出在

string s2 = s;

和之前 Load 函式中的
<pre>
fread((char*)s.c_str(), sizeof(char), size, fp);
</pre>
也就是 string 的 copy-on-write 實現上。

（之前的問題是隱藏在各種程式碼之間，甚至都很難定位到原來是 string 的問題。）

C++ stl::string 有兩種常見的主流實現方式:

<strong>eager-copy</strong>
每個 string 都是一個獨立申請的記憶體空間，每次拷貝都是深拷貝， 哪怕內容是一模一樣的， 所以每個 string 的 c_str() 指標地址都是不一樣的。 這樣的優點是記憶體空間互不干擾， 缺點是記憶體浪費。

<strong>copy-on-write</strong>
string 之間拷貝時不是深拷貝，只拷貝了指標， 也就是共享同一個字串內容， 只有在內容被修改的時候， 才真正分配了新的記憶體並 copy 。 比如 s[0]='1' 之類的修改字串內容的一些write操作， 就會申請新的內容，和之前的共享記憶體獨立開。 所以稱之為 『copy-on-write』

最顯然的就是 string s2 = s; 拷貝後， s 和 s2 的 c_str() 返回的指標地址是 一樣 的。 這樣的優點就是節省記憶體開銷， 當string字串佔用記憶體較大時， 也可以省去深拷貝時較大的效能開銷。

不同的stl標準庫實現不同， 比如 Centos 6.5 預設的 stl::string 實現就是 『copy-on-write』， 而 Mac OS X (10.10.5) 實現就是 『eager-copy』。

而這次的 bug 就是和 『copy-on-write』有關，

因為 s2 和 s 的 c_str() 指標是同一個， 所以 Load 函式裡面的這行程式碼：
<pre>
fread((char*)s.c_str(), sizeof(char), size, fp);
</pre>

我們以為只是在操作一個字串， 其實是 s 和 s2 兩個字串的內容都被修改了。 所以就會導致一系列的問題。

完整示例程式碼請看 stringload

總結###

總之，原因的源頭在於 (char*)s.c_str() ， 雖然我在 StackOverFlow 上有些高票答案也經常使用類似的把 string 當成記憶體緩衝區的寫法。 畢竟方便嘛。但是考慮到 stl 的 copy-on-write 實現，會導致把 stl 容器當記憶體緩衝區的寫法變得有隱藏陷阱。

雖然我在解決這個 bug 之前就知道 stl 有 『copy-on-write』 實現這麼一說。 但是開發時候往往出現問題的地方並不是直接在有問題的程式碼那裡就出現問題， 導致很難查，更何況不知道 『copy-on-write』這回事的開發者，可能就容易踩大坑了。

原文地址:http://blog.jobbole.com/100844/