我正在升級一個稍舊的C++項目使用C++ 11（也許C++ 14）。我試圖儘可能多地使用標準，因爲這個項目是跨平臺的（Win，Mac，Linux），Boost不是一種選擇。使用std :: unique_lock打破XP兼容性時顯式動態鏈接DLL
該項目是一個SDK，需要支持Windows XP SP3及更高版本。 它使用Visual Studio 2015中的v140_xp CRT。
我發現如果我使用某些C++ 11函數，CRT會在.dll中添加.tls節（線程本地存儲），如的std :: unique_lock。雖然，更具體地說，只有當我在unique_lock上調用.lock/.unlock（）時，因爲使用unique_lock似乎使得它基本上是一個不存在問題的std :: lock_guard。
除了XP和Server 2K3以外，在任何版本的Windows上都沒有TLS問題，只有當您顯式動態鏈接dll（使用LoadLibrary）時纔會出現這些問題。如果使用.lib文件隱式鏈接，則一切正常，因爲隱式.tls會被轉換爲鏈接二進制文件，但通過顯式鏈接，您將從LoadLibrary獲得Windows錯誤代碼998。
在XP這種隱性的TLS問題在這裏詳細解釋：Nynaeve: Thread Local Storage, part 6
由於我使用的是XP兼容CRT，我沒想到會遇到不兼容XP，像這樣的。我（親自）認爲這是CRT版XP中的一個錯誤，因爲它不完全兼容XP。
有沒有人遇到過這個問題？是否有任何已知的解決方法（除了滾動我自己版本的使用TLS的所有CRT函數）？
由於這是一個SDK，它需要成爲老版本的替代品（我將靜態鏈接運行時），並且我無法添加我們的客戶將其代碼重寫爲不使用LoadLibrary的要求。
這不是一個在庫中的bug，因爲它是操作系統的限制。操作系統的侷限性不在於圖書館的錯誤。 （您可能希望圖書館解決操作系統限制，但這與說缺乏這種解決方法是一個錯誤並不相同。） –
是否可以鏈接到靜態C++運行庫？ –
@RaymondChen您是正確的，但考慮到Microsoft爲Windows提供的運行時，具有XP兼容性的特定目的使我感覺不同。 – incarnate