C++之stl::string寫時拷貝導致的問題
來自： http://yanyiwu.com/work/2016/01/30/copy-on-write-stl.html
前幾天在開發某些數據結構到文件的 Dump 和 Load 功能的時候， 遇到的一個 bug 。
【問題復現】
問題主要出在 Load 過程中，從文件讀取數據的時候， 直接使用 fread 的去操作 string 的內部指針地址 (char*)s.c_str() 。 簡化后的示例代碼如下（ testdata1 文件內容是12345）：
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);
}通過 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</pre>
注: 因為 testdata1 文件內容是 12345 的純文本文件。
所以 Load(s, 0, 3) 內容就是 “123” ，依此類推。
</div>
但是當后面的 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』這回事的開發者，可能就容易踩大坑了。
</div>
</code></code></code></code></code>
本文由用戶 phpde1 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！