前幾天在開發(fā)某些數(shù)據(jù)結(jié)構(gòu)到文件的 Dump 和 Load 功能的時候， 遇到的一個 bug 。
問題復(fù)現(xiàn)###
問題主要出在 Load 過程中，從文件讀取數(shù)據(jù)的時候， 直接使用 fread 的去操作 string 的內(nèi)部指針地址 (char)s.c_str() 。 簡化后的示例代碼如下（testdata1文件內(nèi)容是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() 分配內(nèi)存空間。 通過 string::c_str() 直接獲取內(nèi)存空間的起始地址并寫入數(shù)據(jù)。
這樣的用法是典型的使用 string 當數(shù)據(jù)緩沖區(qū)的用法， 省去了 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 文件內(nèi)容是 12345 的純文本文件。 所以 Load(s, 0, 3) 內(nèi)容就是 “123” ，依此類推。
但是當后面的 string s2 = s; 定義了一個和 string 變量 s2 。 此時 Load(s2, 1, 3); 時 s2 內(nèi)容是 “234” 符合預(yù)期。
但是問題出在之后 s 的內(nèi)容也變成了 “234” ， 而不是保持原來的 “123” 。
原因分析###
其實示例代碼寫成那樣，問題也清楚了很多了， 問題就出在
string s2 = s;
和之前 Load 函數(shù)中的
<pre>
fread((char*)s.c_str(), sizeof(char), size, fp);
</pre>
也就是 string 的 copy-on-write 實現(xiàn)上。
（之前的問題是隱藏在各種代碼之間，甚至都很難定位到原來是 string 的問題。）
C++ stl::string 有兩種常見的主流實現(xiàn)方式:
<strong>eager-copy</strong>
每個 string 都是一個獨立申請的內(nèi)存空間，每次拷貝都是深拷貝， 哪怕內(nèi)容是一模一樣的， 所以每個 string 的 c_str() 指針地址都是不一樣的。 這樣的優(yōu)點是內(nèi)存空間互不干擾， 缺點是內(nèi)存浪費。
<strong>copy-on-write</strong>
string 之間拷貝時不是深拷貝，只拷貝了指針， 也就是共享同一個字符串內(nèi)容， 只有在內(nèi)容被修改的時候， 才真正分配了新的內(nèi)存并 copy 。 比如 s[0]='1' 之類的修改字符串內(nèi)容的一些write操作， 就會申請新的內(nèi)容，和之前的共享內(nèi)存獨立開。 所以稱之為 『copy-on-write』
最顯然的就是 string s2 = s; 拷貝后， s 和 s2 的 c_str() 返回的指針地址是 一樣 的。 這樣的優(yōu)點就是節(jié)省內(nèi)存開銷， 當string字符串占用內(nèi)存較大時， 也可以省去深拷貝時較大的性能開銷。
不同的stl標準庫實現(xiàn)不同， 比如 Centos 6.5 默認的 stl::string 實現(xiàn)就是 『copy-on-write』， 而 Mac OS X (10.10.5) 實現(xiàn)就是 『eager-copy』。
而這次的 bug 就是和 『copy-on-write』有關(guān)，
因為 s2 和 s 的 c_str() 指針是同一個， 所以 Load 函數(shù)里面的這行代碼：
<pre>
fread((char*)s.c_str(), sizeof(char), size, fp);
</pre>
我們以為只是在操作一個字符串， 其實是 s 和 s2 兩個字符串的內(nèi)容都被修改了。 所以就會導(dǎo)致一系列的問題。
完整示例代碼請看 stringload
總結(jié)###
總之，原因的源頭在于 (char*)s.c_str() ， 雖然我在 StackOverFlow 上有些高票答案也經(jīng)常使用類似的把 string 當成內(nèi)存緩沖區(qū)的寫法。 畢竟方便嘛。但是考慮到 stl 的 copy-on-write 實現(xiàn)，會導(dǎo)致把 stl 容器當內(nèi)存緩沖區(qū)的寫法變得有隱藏陷阱。
雖然我在解決這個 bug 之前就知道 stl 有 『copy-on-write』 實現(xiàn)這么一說。 但是開發(fā)時候往往出現(xiàn)問題的地方并不是直接在有問題的代碼那里就出現(xiàn)問題， 導(dǎo)致很難查，更何況不知道 『copy-on-write』這回事的開發(fā)者，可能就容易踩大坑了。
