I tried a svn build of clang++ two months ago on our in-house code base of hundreds of thousands of lines of C++. I didn't see much advantage to using it.
- I felt misled by all the advertising on the website. They are comparing to Apple's version of gcc-4.2. The last GNU release of gcc-4.2 was two and a half years ago. Even Debian stable has something newer. Compared to gcc-4.2, the newer gcc-4.5 compiles faster, produces faster code, and gives better diagnostics. The comparison on the website was not useful for me to predict the differences now.
- In terms of compile speed, clang was sometimes faster and sometimes slower than gcc-4.5, but overall the differences were very minor.
- In terms of performance, clang was >10% slower, which is OK for debugging builds.
- The diagnostics were a little prettier than gcc-4.5's, but not a huge improvement. I think it was mostly because they were in color.
- Getting the existing codebase to compile was a chore. gcc bends the rules of the C++ standard in some ways that don't appear to cause confusion but make the code more pleasant. For example, it allows unqualified lookup into dependent bases of class templates, which means you can write "foo()" instead of "this->foo()" in things that look like class members (see http://clang.llvm.org/compatibility.html#dep_lookup_bases). There are a number of these - look through the page. I felt like clang was being inappropriately pedantic and beating me over the head with the standard. The most frustrating part was that the compiler wasn't confused - the error message gave me a copy/paste set of changes to make.
- On my Debian system, I could not find a set of c++0x headers that clang knew how to compile (the official instructions say "use gcc's"), so I couldn't try out the new standard.
Just FYI: The reason they're using gcc-4.2 comparisons is that Apple
employees are banned from using GPLv3 software. E.g. if you report a
bug to them that requires checking out a newer version of GCC they'll
just shrug and say "sorry, but we can't try it out".
Oh, and the diagnostics are much better, and not just because they're
in color. Consider e.g. this program:
hello.c: In function ‘main’:
hello.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘char *’
While clang gives you:
hello.c:5:20: warning: conversion specifies type 'int' but the argument has type 'char *' [-Wformat]
printf("hello %d", "world");
~^ ~~~~~~~
Clang tells you not only the line that had the error but also the
column, then it higlights the %d format argument, and shows you which
argument you gave doesn't fit with it.
Pretty much all of its diagnostics messages are like that. While you
sometimes have to stare at code for 5-10 seconds to see what GCC is
complaining about clang will tell you exactly what the problem is.
"The diagnostics were a little prettier than gcc-4.5's, but not a huge improvement." <- I think this example fits with this description: gcc clearly stated it was the second argument... it is nice that it pointed out to me what the second argument is, but I can count. A little prettier, but not a drastic improvement.
I think what most of us are really looking when someone claims that they have better diagnostics is to do something for cases that are currently incomprehensible. As an example: if you run into an error in a recursive template, sometimes you are scratching your head at an error that seems to have no direct semantic meaning. When I was really doing a lot of C++, I started to accumulate a mental map of "when gcc claims that X has occurred, what that really means is that I should try explicitly adding a template or typename keyword to a nearby expression".
I've seen people new to C struggle with what I think are relatively simple GCC diagnostic messages. I think they're somewhat simple now since I'm used to them and know C.
But pointing out exactly the bit of code that's wrong, and often what you should do about it is - I think - a huge improvement.
- I felt misled by all the advertising on the website. They are comparing to Apple's version of gcc-4.2. The last GNU release of gcc-4.2 was two and a half years ago. Even Debian stable has something newer. Compared to gcc-4.2, the newer gcc-4.5 compiles faster, produces faster code, and gives better diagnostics. The comparison on the website was not useful for me to predict the differences now.
- In terms of compile speed, clang was sometimes faster and sometimes slower than gcc-4.5, but overall the differences were very minor.
- In terms of performance, clang was >10% slower, which is OK for debugging builds.
- The diagnostics were a little prettier than gcc-4.5's, but not a huge improvement. I think it was mostly because they were in color.
- Getting the existing codebase to compile was a chore. gcc bends the rules of the C++ standard in some ways that don't appear to cause confusion but make the code more pleasant. For example, it allows unqualified lookup into dependent bases of class templates, which means you can write "foo()" instead of "this->foo()" in things that look like class members (see http://clang.llvm.org/compatibility.html#dep_lookup_bases). There are a number of these - look through the page. I felt like clang was being inappropriately pedantic and beating me over the head with the standard. The most frustrating part was that the compiler wasn't confused - the error message gave me a copy/paste set of changes to make.
- On my Debian system, I could not find a set of c++0x headers that clang knew how to compile (the official instructions say "use gcc's"), so I couldn't try out the new standard.