为什么叮当不被使用更多？
在C / C ++之前，我已经做了大量的编程，但现在它只占我编程的一小部分（脚本语言更适合于我所做的很多工作）。 我在过去几天一直在做一些C编程项目，并且惊讶地发现我一直忘记了多less个小的语法细节。 更糟糕的是cc / gcc通常有关于这些问题的神秘或非信息性的错误信息（抱歉，我不记得任何具体的例子）。
不久之前，我了解了clang编译器，并决定尝试一下。 错误信息更清晰，帮助我识别和修复语法中的问题。 我的问题是为什么这个工具不被使用/提到比它更多？ 难道它和通常的嫌疑犯（ cc / gcc ）相比是如此新鲜，还是它不支持它们支持的function，还是只是难以获得？ 我很难相信最后一个，因为它是与我的iMac上的开发工具一起安装的，并且需要一个命令（ sudo apt-get install clang ）来安装在我的Ubuntu盒子上。
我的问题是为什么这个工具不被使用/提到比它更多？
这可能是因为历史，也是因为我们人类一般的行为。
传统上，gcc一直是唯一真正的（免费）编译器，可以用来在至less所有免费的* nix克隆上编译C程序。 几乎所有的基本系统和Linux内核，* BSD，现在可能是OSX，和其他编译。
虽然缺陷是在这里和那里，基本上这意味着： 海湾合作委员会的作品 。 如果没有损坏，请不要修理。 除此之外，你现在有一个庞大的用户群，很容易得到gcc的帮助，有很多人使用过gcc，正在使用gcc本身。
一般来说，如果你想把一个巨大的社区从他们习惯的东西转换到别的东西，那么“别的东西”必须显着地“更好”，“更好”往往不够理想，我想你可以find这在社会的许多领域的例子。
铿锵是新的，有些人只是在任务上有点怀疑，如果有错误，如果产生的代码比较慢等等 – 人性中似乎是可疑的 – 新事物是可怕的。 许多人甚至不知道叮当声，许多人不在乎，因为他们对gcc感到满意。
不过，如果你宁愿使用clang，那就去做吧 – 错误信息确实是“更好的”，并且比gcc更容易理解。
铛前端是比较新的。 例如，2010年10月的2.8版本标志着C ++ 98/03支持的完成。
看来，随着成熟度的提高，采用率将会越来越高。 例如，目前正在努力使FreeBSD操作系统（和其他BSD操作系统）与叮当一起构build，消除了对GCC / G ++的依赖。
苹果正在推动LLVM /叮当组合。 他们似乎可能会停止支持其旧的GCC工具链分支（基于4.2），并且完全依赖于用于OSX / iOS开发的clang工具。
Clang在C语言的自定义编译器中的应用也越来越多（例如OpenCL的着色器语言编译器）
LLVM已经出现了一段时间，但至less在我的脖子上 – 它最近才刚刚起色，可能是因为苹果最近一直在大力推销，以在他们自己的工具中用Clang取代gcc -链。
另外，我相信它的C ++支持最近才成为生产级别。 编辑：看来，它甚至还没有。 （见下面的评论。）
另一个因素可能是LLVM在很大程度上受到单一供应商的支持，非苹果开发人员对此非常不信任。
我的问题是为什么这个工具不被使用/提到比它更多？ 与通常的嫌疑人相比，它是如此新鲜吗？
这正是这个原因。 它还是新的，核心function还在积极开发之中。 请记住，现有的项目可能正在使用编译器特有的function，或者使用库和开发人员无论如何都不愿意为可能有意想不到的错误或未知性能/尺寸等的实验工具更换工作工具。 折衷，即使新工具日益变得越来越好。
作为一名学生程序员，我觉得这是一个天赐之物，主要是因为它有帮助和可理解的错误信息。 我主要用C语言编程，但是我也开始用Clang分支到C ++。
至于为什么没有提到更多，我怀疑这是因为GCC已经build立了这么久，对于大多数用户来说，它是编译器。 海湾合作委员会对我来说工作得很好，除了它是一个非常神秘的错误信息，作为学生确实把我扔了很多。
总的来说，我强烈推荐Clang供学生和开发者使用。 由于它现在是苹果和Xcode的官方编译器，我怀疑它的使用和名称识别将迅速取代。 FreeBSD似乎也采用了它作为主要的编译器，尽pipe我怀疑它的受欢迎程度比它被苹果公司采用的程度要小。
附录：由于Clang的竞争，GCC 4.8和4.9中错误信息的清晰度显着提高; 尽pipe我还是觉得Clang更清醒一些，但差距已经显着缩小了。
今天，clang正在取代大部分地方的 gcc。 即大多数* NIX类操作系统和Linux发行版。 一些例子是FreeBSD，Minix和Mac（有点显而易见），它们将clang作为默认编译器进行切换。 我的一些朋友，当我展示他们。
这恕我直言，看起来像一些人有问题，可能在旧版本。 但是，使用铿锵3.0版，我没有任何这个问题。 正如我之前提到的，我在所有新项目中都使用它。 几乎我的默认编译器，有时我做make C=gcc只是看到如何区别铿锵的错误/警告。 铿锵赢了。 有了更好的解释和努力优化。 它包括对编译器使用扩展（有些是gcc inerhid）的build议，以便在代码生成中达到最佳性能。
我写了一个简单的函数，打印一个错误消息。 但是，在标准输出上打印错误信息后，我会退出程序。 所以，我做了一个简单的修改，在函数中放了一个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); }
所以铿锵的表演
警告：函数'错误'可以用属性'noreturn'[-Wmissing-noreturn]声明
（ -Wall -Wextra -Wunreachable-code -O3不会产生它甚至没有 – -Wall -Wextra -Wunreachable-code -O3无法-Wall -Wextra -Wunreachable-code -O3标志）
我说：“那看起来不错，但是什么是”不归零“的属性？我从来不听或读这个，我跳到谷歌searchclang could be declared with attribute 'noreturn' （哦，是啊，我可以书面clang nonreturn attribute ，但忘了它），我发现this链接与一个很好的解释这个属性和我可以获得的性能的可能获得。
所以我运行将这个属性添加到我的函数原型（当然，如果它是gcc或clang编译器，macros将执行技巧检测）。 噢，对我来说，任何小小的性能提升（当然，没有使代码无法读取），这是一个胜利。
不要在这里结束，一年前，我在一个函数中return一个函数，这个函数是一个默认处理定义的开关（就像这里的error()函数）。 但即使如此，海湾合作委员会关于函数没有返回值clauses（对不起，我不记得完全错误/警告消息）如何可能？ 在切换后没有更多的语句，如果没有大小写匹配，默认值被执行，并且不关心下面的语句，如果有的话。 但是铿锵和我一样思考不同，并且对这个声明发出警告，帮助我做出更好的代码。
而对于这种非常小的事情，我很喜欢叮当声。 （注意：对于我的英语不好，我很抱歉，英语不是我的母语，但尽pipe如此，我仍然试着在这里expression我的意思）
