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