<div class="gmail_quote">On Mon, Oct 31, 2011 at 1:29 PM, Miles Bader <span dir="ltr"><<a href="mailto:miles@gnu.org">miles@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1m9">But I use both, and my impression is that clang's advantages in these<br>
areas are a bit overstated -- in my typical usage, clang seems "a<br>
little" faster, but it's typically on the order of 10% or so (on C++<br>
code with "medium" template usage), and in general, I've found nothing<br>
particularly wrong with gcc's error messages (there are surely extreme<br>
cases where they're confusing, but really that's true for any<br>
compiler).</div></blockquote><div><br></div><div>I just want to provide a different perspective. I'm not trying to start a deep argument about the virtues of different compilers, I just want to share my observations of Clang as it is used in practice by a reasonably large group of developers.</div>
<div><br></div><div><span style="background-color: transparent; ">When we (Google) started experimenting with Clang, there were many with a perspective similar to yours. However, with over 6 months of having its diagnostics in front of thousands of developers, we've come to a different conclusion.</span></div>
<div><br></div><div>The overwhelming feedback from C++ developers has been that the diagnostics from Clang are significantly more clear and helpful. Clang explains how macros and templates were involved when a particular error is hit, and this is cited repeatedly as being a fundamental shift in the utility of diagnostics for C++ code.</div>
<div><br></div><div>Moreover, the way Clang structures its warnings (not errors) allows for greater precision and lower false positive rates. It doesn't use the optimizer to produce analysis-based warnings, instead providing a more stable and source-based analysis framework for them. It has changed how warnings are perceived in our development community, and we now rely heavily on Clang to warn about dangerous programming constructs.</div>
<div><br></div><div>That said, while the feedback was overwhelmingly positive, there were definitely some who were less enthusiastic. Many of these people had worked with GCC for so long that they exhibited strong change aversion. The messages from GCC are very familiar, and map to an existing set of problem descriptions for these people. They faced a learning curve when the messages changed *at all*, and that was costly. Interestingly, for a surprising number of people in this bucket, after a few months of using Clang, they were reluctant to switch back. They had slowly noticed and started using several common elements of Clang's diagnostics (such as typo-correction and macro backtraces) without even realizing it. When they looked at GCC's messages, they didn't have the information they wanted to understand the problem.</div>
<div><br></div><div>Naturally, YMMV, but this has been our experience with Clang's diagnostics. As a consequence, we take a very active role in maintaining and improving them.</div></div>