为什么编译器不支持C++ 11 thread_local存储？

AFAIK g ++和cl都支持编译器特定的TL存储...所以我想知道的是C++ 11 TLS不同于他们现在支持的东西吗？为什么编译器不支持C++ 11 thread_local存储？

线程本地存储（TLS）是通过其在给定的多线程进程的每个线程可以分配在其中存储线程特定数据的位置的方法。通过TLS API（[TlsAlloc]，[TlsGetValue]， [TlsSetValue]和[TlsFree]）支持动态绑定（运行时）线程专用的数据。除了现有的API实现之外，Win32和Visual C++编译器现在支持每个线程数据的静态绑定（加载时间）。

也适用于VS 支持列为部分。对于g ++，它甚至不在GCC4.7中

来源

2011-11-05 NoSenseEtAl

嗯，MS中的*“partial”*支持意味着，*“我们有一个相似的特性，只是它不是C++ 11的特性，但是在相同的平台相关代码中使用完全不同的语法和结果可能已经在C++ 11之前写了几年*，因此简单地翻译为*“no”*。 –

鉴于2013年4月以前只有GCC 4.8支持此功能，因此可能并不容易。实际上，只有GCC 4.8支持'thread_local'的构造和销毁语义。如果你想在GCC 4.7（或更早的版本）或MSVC中的'__declspec（thread）'中用'__thread'定义一个C++对象（具有构造函数或析构函数），编译器将会抱怨。铿锵编译我的对象用'__thread'标记好，但它不会为每个新线程创建对象。 –

该标准仅在一个月前发布。我相信很多设计会议等都是在他们开始如此艰巨的任务之前进行的。顺便说一句，大多数C++编译器不完全支持标准的C++ 98版本 - 所以要有耐心。

来源

2011-11-05 23:07:41

大多数编译器从不会支持C++ 98，仅仅是因为导出的模板。这并不是说他们没有解决这个问题，而是因为它包含在标准中是一个错误，因为唯一一个实施它的供应商（EDG）要求在C++ 11中删除它。由于这个叮当声和g ++可能会在C++ 98支持之前完全支持C++ 11。 – je4d

使用g ++，它非常接近，至少对于基于ELF的系统。只需编译
-Dthread_local=__thread并且你得到了大部分 - 唯一的问题是未调用构造函数和析构函数，但只要你使用线程局部变量的POD类型，这不是问题。

来源

2011-11-05 23:09:44

tnx的信息，但const/dest的东西使它几乎无用的非平凡的数据。但很高兴知道这一点。 Tnx很多！ – NoSenseEtAl

您可以通过将线程局部变量var指针指向顶层线程主函数中的本地变量来解决ctor/dtor问题。 –

嗯，我不完全知道这个技巧会如何工作。如果你有时间，请发布最短的代码示例。我的意思是你认为如果thread_local ptr == nullptr do ptr = new Object。并为析构函数调用ptr-> manualDestructor？ – NoSenseEtAl

为什么编译器不支持C++ 11 thread_local存储？

回答

相关问题