为什么编译器不支持 c++11 thread_local 存储？ [关闭]答案

【问题标题】：why compilers dont support c++11 thread_local storage? [closed]为什么编译器不支持 c++11 thread_local 存储？ [关闭]
【发布时间】：2011-11-05 23:02:03
【问题描述】：

AFAIK g++ 和 cl 都支持编译器特定的 TL 存储......所以我想知道 C++11 TLS 与他们现在支持的不同吗？

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

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

【问题讨论】：

嗯，MS 术语中的 "partial" 支持意味着，"我们有一个类似的功能，只是它不是 C++11 的功能，而是完全使用不同的语法和结果会产生相同的平台相关代码，您可以在 C++11" 之前编写多年，因此可以简单地转换为 "no"。
鉴于截至 2013 年 4 月只有 GCC 4.8 支持此功能，这可能并不容易。事实上，只有 GCC 4.8 支持thread_local 的构造和销毁语义。如果您想在 GCC 4.7（或更早版本）中使用 __thread 或在 MSVC 中使用 __declspec(thread) 定义 C++ 对象（具有构造函数或析构函数），编译器会报错。 Clang 可以很好地编译我用__thread 标记的对象，但它不会为每个新线程创建对象。

标签： c++ compiler-construction c++11 thread-local

【解决方案1】：

使用 g++，它非常接近，至少对于基于 ELF 的系统而言。只需使用
-Dthread_local=__thread 编译即可获得大部分内容 - 唯一的问题是没有调用构造函数和析构函数，但只要您将 POD 类型用于线程局部变量，这不是问题。

【讨论】：

tnx 的信息，但 const/dest 的东西使它对非平凡的数据几乎无用。但仍然很高兴知道这一点。 Tnx 很多！
您可以通过将线程局部变量设为指针并将其指向顶级线程主函数中的局部变量来解决 ctor/dtor 问题。

【解决方案2】：

该标准仅在一个月前发布。我敢肯定，在他们开始执行如此艰巨的任务之前，许多设计会议等都在进行。顺便说一句，大多数 c++ 编译器并不完全支持标准的 C++98 版本——所以请耐心等待。

【讨论】：

大多数编译器永远不会支持 C++98，仅仅是因为导出了模板。并不是他们没有解决这个问题，而是将其包含在标准中是一个错误，因为唯一实现它的供应商 (EDG) 要求在 C++11 中将其删除。因为这个 clang 和 g++ 可能会在 C++98 支持之前完全支持 C++11。