How to convince any C developer to dump gcc and use clang

According to the clang home page as of March 7th 2010, "Clang's C++ support is currently alpha quality at best, but is evolving rapidly."<p>Obviously, clang does not mean to attract C++ developers. For a while, I'd been adamant about developing in C and not C++. One day I discovered that I'd hand-coded a vtable in order to allow polymorphism in structures of function pointers. The next day, I halved the project complexity by writing 3 classes and changing a flag in the make configuration.<p>I use Gnu make through the Eclipse CDT on Ubuntu. It's a clunky and ugly toolchain/IDE combo that took days to configure. It compiles C, C++, CUDA and Brook+ in the same project across 3 different computers. A better C frontend would be nice, but I do not look forward to getting that working with everyone else in this chain.

I've had 40% speed-ups on some math-heavy C code simply by switching from gcc to clang.

Since when is it hard to find and correct syntax errors that are preventing your C code from compiling?

I am currently switching between gcc and clang for my codebase. The performance is mixed. For some programs (2-level hashtable, for example), the clang version got about 50% speed up against gcc and icc. But other programs (sobel filter for example), clang version slows down about 25% (against gcc 4.4). The result certainly machine specific, but I think clang can do better in a long run.

As a dynamic language guy, I can't help but look at the static analysis here and feel a twinge of jealousy. There really isn't anything like this in the Ruby world.<p>Some stuff is starting to emerge, but we're still largely dependent on tests to catch stupid mistakes. When I'm chasing down a bug, it would be nice to have a variety of tools to throw at the problem.

An even better reason to use clang: it supports Apple's new syntax for blocks. I'm trying to think of a new project to write in C now just to take advantage of the simple anonymous functions and closures that are possible.

I think for many large projects (&#62; 100k lines of code at least, I guess) compilation speed can be critical.<p>GCC is not perfect, but works well enough, is stable enough, that to switch without a strong argument is going to be a slow process at best.

Now, now. LLVM and clang are very interesting projects but changing compilers just because of one feature isn't smart. GCC is good enough in that area and the code it generates is amazing, it often beats every other C compiler out there. And that helps keeping readable code optimized.<p><a href="http://lambda-the-ultimate.org/node/3674" rel="nofollow">http://lambda-the-ultimate.org/node/3674</a>

I use it as a static analyzer for iPhone projects and it creates a nice summary of issues (as linked to) on a web page

Part of being a C developer (or C++ template) developer is in fact understanding what the compiler spits out. So, this did't convine me enough because "two or more data types" made me skip right a head to the definition of Point. :-)<p>My point is Clang is good but friendly error messages is not the only reason I would change to Clang.

I'm not sure this screenshot is convincing. Do you see the last error message?<p>In the second error message clang found that `horisontal` doesn't exist and suggested `horizontal`. That's fair enough. The last error message actually assumes the code said `horizontal`, which is just horribly wrong. I think that the compiler should never ever report an error on code that is not really there. What would happen if the programmer got a list of error and started fixing from the end? What if the guessed name was wrong? The programmer would spend time chasing some bug which doesn't exist outside of compiler's "that's what you probably meant" version of code.

You don't have to convince me — you have to convene me.<p>I'm excited about clang but it's not <i>that</i> important: gcc is good enough. I'll just wait until I can install it from Ubuntu repositories, and then I'll happily try out and hopefully switch over to clang.

clang has a nice interface, but also a long way to go; gcc has earned people's trust because it's been around for a while..

Wow, the clang error messages are really good. I've never seen a compiler produce such user-friendly error messages.

It's intuitive and shows new-world thinking. Most gcc developers are too old to care about doing such enhancements to gcc. They wouldn't change it just for the sake of status quo. As of 2010 we do need stuff like this, though gcc still has enough many traits not to switch to another compiler.

better error messages are really sweet, but ultimately the most important things are 1. better performing code and 2. shorter compile times.

you're saying I should port all my code just because the ui is more user-friendly? what about performance, options, special warnings, builtins, and everything else?<p>I've been using gcc for a while now, and every time I use it I found a new feature. It's rock solid and had never let me down.

By this logic it should be easy to convince people using gcc to switch to Xcode.