Clang 2.8 release now considered "production ready"
cplusplus-soup.com
cplusplus-soup.com
- 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.
Oh, and the diagnostics are much better, and not just because they're in color. Consider e.g. this program:
#include <stdio.h>
int main(void)
{
printf("hello %d", "world");
return 0;
}
hello.c: In function ‘main’:
hello.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘char *’
hello.c:5:20: warning: conversion specifies type 'int' but the argument has type 'char *' [-Wformat]
printf("hello %d", "world");
~^ ~~~~~~~
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.
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".
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.
* It has much better diagnostics messages: http://clang.llvm.org/diagnostics.html
* Compilation times are much faster, even though I always wrap gcc/clang with ccache.
* It uses a lot less CPU / memory on equivalent compile options.
The only disadvantage is that compared to GCC 4.4 the resulting binaries are usually around 5-10% slower. The LLVM developers say that's to be expected, currently they're targeting GCC 4.2 for their performance metrics.
But of course if you're producing binary packages you may want to use other criteria than compilation speed and diagnostic messages to select the compiler.
Because it's fast and pretty small, Clang is probably the best thing you can use during development, but in my experience — no 2.8 yet of course — it produces binaries pretty consistently slower than gcc's and is therefore a worse option for production (and for CI servers and integration of course)
I can't say I understand why anyone would care too much about compilation speed, though - GCC+ccache is about as fast as Clang+ccache, as the primary bottleneck is disk throughput.
I often compile code that has not been compiled before. For example when using MacPorts.
Never underestimate how much people like speed. I never thought SVN was slow or that I needed speed, until I tried git and realized I could not even consider using something slower.
That's one of the main reasons I like Go. It's been explicitly designed to enable fast compilation, and even at this early stage its compilers are very fast.
I have LLVM 2.7 installed and Clang itself says this:
$ clang --version
clang version 1.1