如果Windows上没有线程支持，GCC会死吗？[关闭]

我需要一些意见。GCC一直是一个非常好的编译器，但是最近它失去了“吸引力”。我刚刚发现Windows上没有GCC std::thread支持，由于仍然缺少最激动人心的功能，因此迫使Windows用户使用其他编译器。

但是，为什么GCC确实在Windows下仍然没有线程支持？许可问题？ABI不兼容？（嗯，已经有几个使用多线程的跨平台库：boost，POCO，SDL，wxwidgets等。使用已经存在且已获得MIT / libpng许可的代码来适应这个漏洞而不是发布GCC版本不是很简单吗？没有线程支持？）

最近，通过对编译器的比较，GCC对C ++ 11功能的支持比其他编译器要大，除了在Windows上这不是事实，因为我们仍然缺少原子，互斥体和线程：/

我想了解更多有关此主题的信息，但我唯一能找到的人是寻求帮助的人，因为：

std名称空间中不存在“线程”

从GCC / TDM-GCC的票务跟踪和邮件讨论开始，自2009年以来就一直在寻求线程支持的请求。可能在4年后仍然没有解决方案吗？到底发生了什么事？

我了解到，海湾合作委员会（GCC）之所以失宠，是因为维护它的人变得有些自大，现在LLVM在这里（而且非常好），人们在用脚投票。

Slashdot讨论了LLVM对C ++ 11的新支持。_merlin说：

哦，我认为没有人认为这是邪恶的，只是纯粹出于个人利益而不是慷慨大方。GCC的惊人的普及已经导致其维护日益庞大的自我和行为像总[ * ***。引入缺陷的速度比Red Hat和Apple能够接受它们的补丁要快，而且它们有一种讨厌的习惯，即不查看缺陷报告，然后由于不活动而将其关闭而不进行实际修复

这与您对4年延迟的观察相吻合。

GCC的受欢迎程度和可用性毋庸置疑。

• GCC仍然是出色的编译器，使用最广泛。
• GCC支持clang不针对的语言，例如Java，Ada，FORTRAN等。
• 与LLVM相比，GCC支持的目标更多。
• GCC支持C ++ 11

从 https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw构建于http://code.google.com/p/mingw-builds/downloads/list 支持线程。

但是重要的考虑因素是许可证。

• GCC已根据GPL许可获得许可。clang使用BSD许可证，该许可证可将其嵌入未经GPL许可的软件中。
• 从GCC切换到Clang的主要原因是GCC的GPL v3许可证与FreeBSD项目的目标不兼容。

FreeBSD与GPL有着不安的关系。BSD许可证倡导者认为，真正的免费软件没有使用限制。GPL的倡导者认为，限制是保护软件自由所必需的，特别是从自由软件创建非自由软件的能力是一种不公正的权力形式，而不是自由。FreeBSD项目尽可能尝试避免使用GPL（有关详细信息，请参见 https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm）

其他重要注意事项

来自http://clang.llvm.org/comparison.html#gcc

• 熟悉相关语言并且对编译器的工作有基本了解的任何人都应易于理解Clang AST和设计。GCC的代码库很旧，为新开发人员提供了陡峭的学习曲线。
• Clang从一开始就被设计为API，从而允许源分析工具，重构，IDE（等）以及代码生成对其进行重用。GCC是作为一个整体的静态编译器构建的，这使得它很难用作API并集成到其他工具中。此外，其历史性设计和当前策略使得很难将前端与编译器的其余部分分离。
• 各种GCC设计决策使重用非常困难：其构建系统难以修改，您无法将多个目标链接到一个二进制文件中，您无法将多个前端链接到一个二进制文件中，它使用了自定义垃圾收集器，广泛使用全局变量，不可重入或不可理解等。Clang没有这些问题。
• 对于每个令牌，clang都会跟踪有关其写入位置以及如果它涉及宏，则最终将扩展到何处的信息。解析源代码时，GCC不会跟踪有关宏实例化的信息。这使得源重写工具（例如用于重构）在（甚至简单的）宏的存在下很难工作。
• Clang不会像GCC那样隐式简化代码。这样做会给源代码分析工具带来很多问题：作为一个简单的示例，如果您在源代码中编写“ xx”，则GCC AST将包含“ 0”，而没有提及“ x”。对于要重命名“ x”的重构工具来说，这是非常糟糕的。
• Clang可以将其AST序列化到磁盘上，然后将其读回到另一个程序中，这对于整个程序分析很有用。GCC没有这个。GCC的PCH机制（只是编译器内存映像的转储）是相关的，但在架构上只能将转储读回与生成转储的程序完全相同的可执行文件（这不是结构化格式）。
• Clang比GCC快得多，并且使用的内存少得多。
• Clang旨在提供极其清晰和简洁的诊断（错误和警告消息），并包括对表达诊断的支持。GCC的警告有时是可以接受的，但常常令人困惑，并且不支持表达诊断。Clang还始终如一地保留诊断中的typedef，显示宏扩展和许多其他功能。
• Clang从LLVM作为后端的使用中继承了许多功能，包括对中间代码的字节码表示形式的支持，可插拔的优化器，链接时优化支持，即时编译，在多个代码生成器中进行链接的能力等。 。
• Clang对C ++的支持在许多方面（例如，一致的两阶段名称查找）比GCC更兼容。

从 http://www.linuxquestions.org/questions/slackware-14/gcc-vs-llvm-931034/

• llvm / clang的优点是其模块化设计，因此可以进行
  接口连接并用于例如创建静态代码分析工具，这变得越来越重要（）

从http://clang.debian.net/

• clang现在准备构建用于生产的软件（针对C，C ++或Objective-C）。与gcc套件相比，此编译器提供了更多的警告和有趣的错误，而没有与gcc相同的遗产。

之所以要花费很多时间，是因为要花费大量的时间才能建立一个坚实的基础来构建标题。mingw-w64似乎采用的方式是在Windows上构建一个类似于pthreads的稳定库。与引入Windows API的本机线程的依赖相比，上游的抱怨更少。

mingw-w64实现<thread>和其他C ++ 11标头位于其自己的winpthreads库的顶部。这应该可以在Mingw-w64工具链的Mingw版本和rubenvb发行版中进行测试。如果您想跟踪本机Windows GCC工作的大部分工作在哪里完成，我建议遵循mingw-w64邮件列表。

Qt项目有一个Wiki页面，详细介绍了他们当前的建议以及Windows上GCC工具链的概述，请参阅Qt Project Wiki页面。