为什么没有更多地使用clang？ [关闭]答案

【问题标题】：Why is clang not used more? [closed]为什么没有更多地使用clang？ [关闭]
【发布时间】：2011-06-20 15:08:33
【问题描述】：

我以前用 C/C++ 进行过相当多的编程，但现在它只占我所做编程的一小部分（脚本语言更适合我所做的很多工作）。过去几天我从事了一些 C 编程项目，我很惊讶自己忘记了多少语法细节。更糟糕的是，cc/gcc 通常有关于这些问题的神秘或非信息性错误消息（抱歉，我不记得任何具体示例）。

不久前我了解了clang 编译器，并决定尝试一下。错误消息更加清晰，帮助我识别和修复语法中的问题。我的问题是为什么这个工具没有被更多地使用/提及？是它与通常的嫌疑人（cc/gcc）相比太新了，还是它不支持他们支持的功能，或者只是更难获得？我很难相信最后一个，因为它是与我的 iMac 上的开发工具一起安装的，并且需要一个命令 (sudo apt-get install clang) 才能安装在我的 Ubuntu 机器上。

【问题讨论】：

你最好等 XCode4，然后你会看到 clang 的使用量会飙升。
注意：CLang 对 C 的生产已经成熟，但是对 C++ 的支持仍在进行中，C++03 通常很好，但是 C++0x 落后于 wrt VC++ 和 gcc。不过它正在积极开发中。
我曾经在 GCC 中编写 C，因为，嗯，这个是编译器，我想我必须跳出框框看看，我真的很喜欢它的表现力编译器投诉，+1 介绍此编译器。
我主要使用gcc，只有在编译失败和gcc的错误信息太无用时才切换到clang；另外，我在我的一个程序中遇到了段错误，我不记得在 gcc 中发生过这种情况......
我在 VIM 中使用了 clang_complete 插件，是的，clang 错误消息是富有表现力的。

标签： c++ c compiler-construction clang

【解决方案1】：

作为一名学生程序员，我发现它完全是天赐之物，主要是因为它有用且易于理解的错误消息。我主要将它用于 C 编程，尽管我也开始使用 Clang 扩展到 C++。

至于为什么没有多提，我怀疑是因为GCC成立这么久，对于大多数用户来说它是THE编译器。 GCC 对我来说工作正常，除了它是非常神秘的错误消息，作为一个学生确实让我很反感。

总的来说，我强烈推荐 Clang 供学生和开发人员使用。由于它现在是 Apple 和 Xcode 的官方编译器，我怀疑它的使用和名称识别将很快得到提升。 FreeBSD 似乎也采用了它作为他们的主要编译器，尽管我怀疑这对它的流行度的影响要小于它被 Apple 采用的影响。

附录： 由于来自 Clang 的竞争，GCC 4.8 和 4.9 中错误消息的清晰度有了显着的提高；虽然我仍然觉得 Clang 更清晰一些，但差距已经明显缩小。

【讨论】：

【解决方案2】：

今天，clang 正在替换大多数places 中的 gcc。即，大多数*NIX-like操作系统和Linux发行版。一些示例 oare FreeBSD、Minix 和 mac（有点明显）clang 将 clang 切换为默认编译器。当我向他们展示时，我的一些朋友也是如此。

这个恕我直言，看起来有些人有问题，可能在旧版本中。但是使用 clang 3.0 版，我没有任何这些问题。正如我之前提到的，我在我所有的新项目中都使用了它。几乎是我的默认编译器，有时我会make C=gcc 只是为了看看clang 错误/警告的区别。和铿锵永远。用更好的解释和努力优化。它包括对编译器的使用扩展（有些是 gcc inerhid）的建议，以在代码生成中获得最佳性能。

我编写了一个打印错误消息的简单函数。但是我会在标准输出上打印错误消息后退出程序。所以，我做了一个简单的修改，把exit(1)作为函数的最后一条语句。如下：

void error(const char *fmt, ...)
{
  va_list ap;
  va_start(ap, fmt);
  fprintf(stderr, "error: ");
  vfprintf(stderr, fmt, ap);
  va_end(ap);
  exit(1);
}

于是铿锵秀

警告：函数 'error' 可以用属性 'noreturn' 声明 [-Wmissing-noreturn]`

（即使没有-Wall -Wextra -Wunreachable-code -O3 标志，gcc 也不会产生它）

我说“这看起来不错。但什么是 'nonreturn' 属性？我永远不会听或读到这个。我跳到谷歌搜索 clang could be declared with attribute 'noreturn' （哦，是的，我可以写 @987654328 @，但算了），我发现 this 链接很好地解释了这个属性是什么以及我可以获得的性能增益。

所以我跑来将此属性添加到我的函数原型中（当然，如果它是 gcc 或 clang 编译器；宏会进行技巧检测）。哦，是的，对我来说，任何小的性能提升（当然，没有使代码不可读）它是一个胜利。

而且不要在这里结束，一年前，我在一个函数中创建了return，其中以前是一个开关作为定义的默认处理（如error() 函数在这里）。但即便如此，gcc 声称没有返回值的函数（对不起，我不记得确切的错误/警告消息）怎么可能？ switch 后没有更多的语句，如果没有匹配，则执行默认值，如果有的话，下面的语句并不重要。但是 clang 想法不同，像我一样，并对此声明发出警告，帮助我编写更好的代码。

对于这种非常小的东西，我喜欢铿锵声。（注意：我很抱歉我的英语不好。英语不是我的母语，但尽管如此，我还是想在这里表达我的意思）

【讨论】：

在需要“优化”的程序的所有领域中，我想退出应用程序的性能是最不关心的。
这里的优化是1）当编译器看到“nonreturn”属性时； 2）由我删除死代码-Wunreachable-code
在大部分地方显然是不真实的，即使根据您自己提供的链接也是如此。

【解决方案3】：

clang 前端相对较新。例如，2010 年 10 月的 2.8 release 标志着 C++ 98/03 支持的完成。

随着成熟度的提高，采用率似乎会越来越高。例如，目前正在进行使用 clang 构建 FreeBSD 操作系统（和其他 BSD 操作系统）的工作，以消除对 GCC/G++ 的依赖。

Apple 正在推动 LLVM/clang 组合。他们似乎很可能会停止支持旧的 GCC 工具链分支（基于 4.2），并开始完全依赖 clang 工具进行 OSX/iOS 开发。

Clang 也越来越多地被用于类 C 语言的自定义编译器（例如用于 OpenCL 的着色器语言编译器）中采用

【讨论】：

【解决方案4】：

LLVM 已经存在了一段时间，但是——至少在我的圈子里——它最近才变得突出，可能是因为苹果最近一直在大力推动用 Clang 取代 gcc他们自己的工具链。

另外，我相信它的 C++ 支持最近才成为生产级。 编辑： 似乎还不是那样。（参见下面的 cmets。）

另一个因素可能是 LLVM 主要由单一供应商提供支持，非 Apple 开发人员对此抱有天生的不信任。

【讨论】：

它不是生产级的，只是功能完整 (C++03)。例如。它无法正确编译 Qt AFAIK（它确实编译但单元测试显示回归）。
@Tamás：感谢您的评论。我已经修改了答案。
+1，我会为最后一句话添加第二个！ 由单一供应商提供支持，非 Apple 开发人员天生对此不信任。
引用 LLVM/Clang 2.8 发行说明“Clang 被认为是 x86（32 位和 64 位）上的 C、Objective-C、C++ 和 Objective-C++ 的生产质量编译器，并且用于达尔文臂目标”。因此，也许生产质量取决于平台。我当然希望它在 OSX 及其目标上运行得最好，因为 Apple 是主要支持者，而 Linux/Unix/Windows 支持则相反是由社区驱动的。

【解决方案5】：

我的问题是为什么没有更多地使用/提及这个工具？是不是和一般的嫌疑人比起来还这么新……

这正是原因。它仍然是新的，核心功能仍在积极开发中。请记住，现有项目可能正在使用特定于编译器的功能 - 或使用的库 - 无论如何，开发人员都不愿意为可能有意外错误或未知性能/大小/等的实验性工具更改工作工具。权衡取舍，即使新工具每天都在变得越来越好。

【讨论】：

请记住，C++ 支持是最近才完成的，并且可能仍然存在一些错误。并且调试符号仍然需要工作（我听说调试符号输出比 GCC 大 5 倍......）
@bdonlan，调试符号大小问题仅在 Linux btw 上。
@bdonlan：我试图用“实验性”来表达这一点，但应该强调这一点。谢谢。

【解决方案6】：

我的问题是为什么这个工具没有被使用/提及更多？

这可能是因为历史，以及我们人类通常的行为方式。

传统上，gcc 是唯一一个真正的（免费）编译器，可以实际用于在至少所有免费的 *nix 克隆上编译 C 程序。它几乎是所有 linux 的基本系统和内核、*BSD、现在可能是 OSX 和其他的编译器。

虽然缺陷无处不在，但基本上这意味着：gcc 有效。如果它没有损坏，请不要修复它。除此之外，您现在拥有庞大的用户群，很容易获得 gcc 的帮助，有很多人使用过 gcc，正在研究 gcc 本身等等。

一般来说，如果你想将一个庞大的社区从他们习惯的东西切换到其他东西，那么“其他东西”必须*明显“更好。仅仅“更好”通常是不够的。我认为你可以在社会的许多领域找到这样的例子。

clang 比较新，有些人会怀疑它是否能胜任任务，如果它有错误，如果它产生较慢的代码等等 - 怀疑似乎是人类的天性 - 新事物是可怕的。许多人甚至不知道 clang，许多人不在乎，因为他们对 gcc 很满意。

不过，如果您更想使用 clang，那就去吧 - 与 gcc 相比，错误消息确实“更好”且更易于理解。

【讨论】：