轉C 之stl string寫時拷貝導致的問題

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

【問題復現】

問題主要出在 load 過程中，從檔案讀取資料的時候，直接使用 fread 的去操作 string 的內部指標位址(char*)s.c_str()。簡化後的示例**如下（ testdata1 檔案內容是12345）：

void load(string& s, size_t offset, size_t size)

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

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

不過這次遇到問題了。

簡化問題**示例如下：

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

注: 因為 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 函式中的

fread((char*)s.c_str(), sizeof(char), size, fp);

也就是 string 的 copy-on-write 實現上。

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

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

『eager-copy』

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

『copy-on-write』

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 函式裡面的這行**：

fread((char*)s.c_str(), sizeof(char), size, fp);

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

完整示例**請看 stringload

【總結】

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

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