C 及標準庫中，其實存在了一些大坑，你都知道怎么避免嗎？ 1、變量初始化 這是使用 C 11 codecvt 時遇到的一個坑，轉換編碼時，mbstate_t 這個中間狀態(tài)變量，必須初始化為0，否則運行出錯，即： 這是第一個坑，并不算太坑，還比較容易調試和發(fā)現(xiàn)，也怪自己大意了。 經(jīng)驗：C 中的變量一定要初始化后再使用。 2、匿名 std::thread 對象 這個坑要和 boost 進行比較，在 boost 中，是可以創(chuàng)建匿名 thread 對象的，并且這樣的匿名對象跟 future、promise是可以正常配合使用的（《Boost標準庫完全開發(fā)指南》一書中的示例代碼就是這樣寫的）。 但是，在 C 標準庫中不能這么干，會出現(xiàn)莫名其妙的錯誤，調試時也不會顯示任何有價值的信息，最終確定這個問題真是費了我好大勁，因為根本沒想到會是這個問題，畢竟 boost 里都正常使用了。 經(jīng)驗：盡量不使用匿名對象，如果想要用完立即釋放，可以使用單獨的代碼塊包裹。 3、線程局部存儲（TLS） 這是一個坑了我一天的大坑。 C 11 中，新引入了 thread_local 存儲類型，等同于之前的 __declspec(thread)，由于其具有真正的可移植性，所以我就嘗試使用了，但這也是噩夢的開始。 我有一段代碼，如果編譯為 exe，在 xp 系統(tǒng)上能正常運行，但如果編譯為 dll，在 xp 上運行就出錯。由于 xp 上不能安裝 VS 這種高科技玩意，只能用 x32_dbg 湊合調試，發(fā)現(xiàn)是空指針異常，指針來源為 fs:[2c]，這是 TLS 指針啊，然后百度，找到了微軟的文檔 ： 是的，如果 dll 中使用了 thread_local，這個 dll 將不能在 xp 上通過 LoadLibrary 動態(tài)加載。 解決辦法也是有的：既然不能通過 LoadLibrary 動態(tài)加載，那我靜態(tài)加載不就行了，只要在編譯 exe 時靜態(tài)鏈接 dll，即 dll 在 exe 的導入表中，那就可以正常運行（這也要求 exe 必須是自己可編譯的）在 DllMain 中使用 TLS 相關的 API 手動初始化。 經(jīng)驗：或許我應該拋棄 xp 了。 4、dll 中的靜態(tài)對象 這個坑跟上個坑是同時出現(xiàn)的，只是我當時用了靜態(tài)鏈接的方式后，就運行正常了，也就沒在意。直到后來又想在 C# 中調用dll，這回沒辦法靜態(tài)鏈接了。為了先實現(xiàn)功能，我選擇了暫時刪除 thread_local，但是在 xp 上依然運行出錯，錯誤原因跟之前一樣！臥槽，我特么明明都刪掉了 thread_local 呀，為何還這樣??！ 又經(jīng)過2個小時的調試，最終確定問題出在 C 17 標準庫中的 std::experimental::filesystem::exists() 函數(shù)，但是經(jīng)過我單步調試發(fā)現(xiàn)，這個函數(shù)并沒有使用 TLS，只用到了一些全局靜態(tài)對象，莫非是全局靜態(tài)對象的問題？ 于是還是找文檔吧，跟上個問題同一個網(wǎng)址 ： 在 C 11 中，靜態(tài)變量的初始化是線程安全的，這個所謂的“線程安全”，就是引入了 TLS 來進行一些額外的檢查，好在這個特性是可以禁用的，編譯時添加 /Zc:threadSafeInit- 選項即可（注意最后的減號），禁用后就不會使用 TLS 了，也就可以在xp 上動態(tài)加載了。 注：這些問題在 VS2015 Update 2 中發(fā)現(xiàn)，應該也會持續(xù)存在于之后的 VS 版本中。 來源：網(wǎng)絡（版權歸原作者所有） (mbbeetchina)