这是使用 C++11 codecvt
时遇到的一个坑,转换编码时,mbstate_t
这个中间状态变量,必须初始化为0,不然运行出错,即:promise
// 不能够! mbstate_t mbst; // 这样能够 mbstate mbst = {0}; // 这样也行 mbstate mbst = mbstate_t();
这是第一个坑,并不算太坑,还比较容易调试和发现,也怪本身大意了。安全
经验:C++中的变量必定要初始化后再使用。 app
这个坑要和 boost 进行比较,在 boost 中,是能够建立匿名 thread 对象的,而且这样的匿名对象跟 future、promise是能够正常配合使用的(《Boost标准库彻底开发指南》一书中的示例代码就是这样写的)。函数
可是,在 C++ 标准库中不能这么干,会出现莫名其妙的错误,调试时也不会显示任何有价值的信息,最终肯定这个问题真是费了我好大劲,由于根本没想到会是这个问题,毕竟 boost 里都正常使用了。编码
经验:尽可能不使用匿名对象,若是想要用完当即释放,可使用单独的代码块包裹。 线程
这是一个坑了我一天的大坑。指针
C++11 中,新引入了 thread_local
存储类型,等同于以前的 __declspec(thread)
,因为其具备真正的可移植性,因此我就尝试使用了,但这也是噩梦的开始。调试
我有一段代码,若是编译为 exe,在 xp 系统上能正常运行,但若是编译为 dll,在 xp 上运行就出错。因为 xp 上不能安装 VS 这种高科技玩意,只能用 x32_dbg 凑合调试,发现是空指针异常,指针来源为 fs:[2c],这是 TLS 指针啊,而后百度,找到了微软的文档 https://msdn.microsoft.com/en... :code
On XP systems, thread_local may not function correctly if a DLL uses thread_local data and it is loaded dynamically via LoadLibrary.
是的,若是 dll 中使用了 thread_local
,这个 dll 将不能在 xp 上经过 LoadLibrary
动态加载。对象
解决办法也是有的:
LoadLibrary
动态加载,那我静态加载不就好了,只要在编译 exe 时静态连接 dll,即 dll 在 exe 的导入表中,那就能够正常运行(这也要求 exe 必须是本身可编译的)DllMain
中使用 TLS 相关的 API 手动初始化经验:或许我应该抛弃 xp 了。
这个坑跟上个坑是同时出现的,只是我当时用了静态连接的方式后,就运行正常了,也就没在乎。直到后来又想在 C# 中调用 dll,这回没办法静态连接了。为了先实现功能,我选择了暂时删除 thread_local
,可是在 xp 上依然运行出错,错误缘由跟以前同样!卧槽,我特么明明都删掉了 thread_local
呀,为什么还这样!!
又通过2个小时的调试,最终肯定问题出在 C++17 标准库中的 std::experimental::filesystem::exists()
函数,可是通过我单步调试发现,这个函数并无使用 TLS,只用到了一些全局静态对象,莫非是全局静态对象的问题?
因而仍是找文档吧,跟上个问题同一个网址 https://msdn.microsoft.com/en... :
Starting in C++11, a static local variable initialization is guaranteed to be thread-safe. This feature is sometimes called magic statics. However, in a multithreaded application all subsequent assignments must be synchronized. The thread-safe statics feature can be disabled by using the /Zc:threadSafeInit- flag to avoid taking a dependency on the CRT.
在 C++11 中,静态变量的初始化是线程安全的,这个所谓的“线程安全”,就是引入了 TLS 来进行一些额外的检查,好在这个特性是能够禁用的,编译时添加 /Zc:threadSafeInit-
选项便可(注意最后的减号),禁用后就不会使用 TLS 了,也就能够在 xp 上动态加载了。
经验:xp 去死吧!去死吧!去死吧!
注:这些问题在 VS2015 Update 2 中发现,应该也会持续存在于以后的 VS 版本中。