
How to convince any C developer to dump gcc and use clang - fseek
http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/
======
ndl
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."

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.

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.

~~~
wtallis
The clang developers fully intend to support C++. It's just a more complex
language, and as an Apple-supported project, C and Obj-C were higher
priorities. clang itself is written in C++ and is self-hosting. I expect that
by the end of next year, it will be able to handle Boost and any other
reasonable C++ code.

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

~~~
cperciva
Which version of gcc?

I had a 2x speedup a few years ago on math-heavy code (FFTs) by switching from
gcc 4.2 to gcc 3.4 -- apparently there was a known issue in gcc's optimizer
where it would flag too many values as "keep this in a register" and end up
spending lots of time moving data to and from the "register overflow space" on
the stack. (I don't know if this has been fixed -- as I said, it was a few
years ago that I ran into this issue.)

~~~
alecco
I second that on gcc version. On many math related code gcc-4.4 is amazing.
Specially if vectorization and/or SIMD is possible.

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

~~~
lolcraft
Why not make it easier if you can? Vagueness is hardly a virtue for a
programming tool. Also, I don't think the ladies are impressed by your cryptic
error fixing skills ;)

What this feature needs now is code correction on the fly. Any error reporter
smart enough to ask "did you mean 'x'?" should allow me to answer "yes", and
write the changes to the file. That would sell clang to a lot of people.

~~~
pieter
there's a command-line option to do just that

------
liuliu
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.

~~~
raeez
Although cryptic, I'd say that gcc's error messages are manageable. I'd hold
other factors, such as performance of compiled code - across platforms - to be
more important. Alternatively, they could improve on the C++ template error
reporting (when they get around to taking C++ support beyond alpha) and that
may be enough to sell me.

a quick search yields <http://clang.llvm.org/performance.html> (favourable,
but somewhat skewed results).
[http://forums.cocoaforge.com/viewtopic.php?f=10&t=21016](http://forums.cocoaforge.com/viewtopic.php?f=10&t=21016)
indicates improved compile times, but it's purely anecdotal.

That said, does anyone else have any experience moving a performance-centric
or cross platform project to clang?

~~~
voidpointer
If clang could come up with better C++ template error messages that would be
really sweet. STL related error messages in g++ (and MSVC) are really hard to
figure out, especially when C++ is not your main language; so you're not
exposed to those problems on a daily basis.

------
megaduck
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.

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.

~~~
sruffell
I spend most of my time writing C code, but like to work with Python when I
get the chance. There isn't anything like pylint for Ruby? A dynamic runtime
doesn't necessarily mean you have to give up static analysis.

~~~
riffraff
roody, rufus, reek, flay, flog, probably more. Sadly, in the current state of
the ruby community it's even hard to find a library that will run with ruby's
own warnings enabled.

~~~
eru
Isn't clean code valued in the Ruby community?

As a contrast, I had the impression that the Python guys care more about this
in their code. They also avoid eval and other runtime code generation. (Though
I do not if that's related.) It seems these two languages are further apart
than in their culture than anything else.

~~~
riffraff
clean code, yes, but some of the warnings are actually generated in situations
where the code won't be cleaner (e.g. lazy initializing an instance variable
not declared in the initialization method) and since quite a lot of the most
common libraries have _a lot_ of warnings, it becomes unlikely that you will
have them enabled in your app, and so the thing self propagates

~~~
eru
OK. So people should suppress the warning in those cases, so as not to
desensitize?

~~~
riffraff
well, I do, but I understand why people don't. The likely better solution
would be to have structured warnings you can enable/disable by, selector such
as warning class, declaring namespace, using namespace or whatever, but that
seems quite unlikely :)

------
mrshoe
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.

~~~
alayne
Proprietary extensions are one reason that gcc is so hard to unseat. You're
always better off writing standard code if you want it to work in ten years.

~~~
jws
Hardly proprietary. Apple gave the "block" patches to the gcc team. Gcc isn't
interested in them, they are holding off for some future C++ syntax, though I
don't see how that helps C programmers.

Meanwhile, I got seduced by gcc's nested functions which are not supported by
clang. Apparently they are non-trivial in clang so won't appear soon if at
all.

Two incompatible mechanisms for function decomposition are annoying.

("blocks" does a lot more, but for the afflicted project I don't need that.
Just nested functions would be spiffy, it saves the plethora of arguments
being passed to each function if you keep them at file scope.)

~~~
CrLf
"Gcc isn't interested in them, they are holding off for some future C++
syntax, though I don't see how that helps C programmers."

You are assuming that C programmers need to be helped.

The beauty of C lies in its simplicity, not in its features. That's what has
kept C alive to this day despite its shortcomings, and despite the existence
of C++.

C does not need new constructs. C needs to be kept as simple and as close as
possible to the hardware, it needs to continue to be a high-level assembly.
That's what C is mostly used for.

If you feel C needs more features, you are probably using the wrong language
for the job.

~~~
jws
Closures in C make me uncomfortable, but lexically scope subfunctions are just
syntax that serve two functions for me.

First: organization. If I grab a chunk of function and put it in nicely named
subfunction, even if it is only called once it lets me keep each function to a
nice size. This could be done with a static function, but then you always have
to think: "What else in this file might call this function?"

Second: (And much more empowering) Gathering together repetitious code can be
cleaner. Consider implementing some network protocol. You will probably have a
"get next byte from buffer" function which will need access to the buffer, the
current position, the number of valid bytes in the buffer, and who knows what
else. You could make this a static function and pass all the arguments in,
correctly, each time and if you only need a single value back that works. With
a lexically scoped subfunction you can just reference these in the outer scope
and if you need to set an error condition or message just set it in the outer.
Very clean. No scary runtime code.

------
antirez
I think for many large projects (> 100k lines of code at least, I guess)
compilation speed can be critical.

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.

~~~
jules
Clang is supposed to be faster than gcc.

------
alecco
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.

<http://lambda-the-ultimate.org/node/3674>

~~~
TwoBit

        >> often beats every other C compiler out there
    

Microsoft and Intel are well-known to generate better code than GCC. So I
don't know what you are referring to with "every other C compiler out there."

------
azsromej
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

~~~
hannibalhorn
Same here - for missing retain/release calls (i.e., stupid memory leaks) it
works great.

------
kvs
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. :-)

My point is Clang is good but friendly error messages is not the only reason I
would change to Clang.

~~~
sad
But it is a compelling reason. Imagine all of the brain cells you can reclaim
by forfeiting that C++ error message intuition that you now have.

First we need full C++ coverage in clang. Onward!

~~~
jules
> Imagine all of the brain cells you can reclaim by forfeiting that C++
> intuition that you now have.

Orders of magnitute more than just for the error messages.

------
viraptor
I'm not sure this screenshot is convincing. Do you see the last error message?

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.

~~~
philwelch
"What would happen if the programmer got a list of error and started fixing
from the end?"

I always fix the first 1 or 2 reported errors and try to recompile. I assume
everyone did. A traditional "report on errors which are actually there each
time they happen" compiler will give you tons of completely spurious errors
which happily disappear once you fix the first few.

In the instance you point out, it could just uselessly say "no member named
horisontal" but it knows it already gave you that error. So instead of
repeating itself or shutting up, it reasons in the alternative--even if the
name was corrected, the type is wrong. I would actually find that far more
useful for fixing all the compiler errors at once.

~~~
nostrademons
I usually try to fix as many errors as I can identify before recompiling. And
yes, I usually fix from the bottom up, because that way my changes don't alter
the line numbers of future fixes. On large projects, recompile time can be
significant.

~~~
demallien
Yes, sure, large projects can take time to compile, but doesn't your compile
environment just try to recompile the last file that it failed on during the
build? That is, if in trying to build my app FooBar, and foo.c compiles ok but
bar.c fails, when I try to run the build the next time having modified bar.c,
it starts by trying to compile bar.c anyway... So I guess what I'm trying to
say is that I don't understand the advantage you are apparently getting by
woring from bottom up.

~~~
nostrademons
I don't want to get into the specifics of the build system since it's
proprietary, but there's a non-trivial startup cost for it. It's optimized for
being able to compile really huge projects in a tractable amount of time, not
being able to recompile individual files in the shortest possible amount of
time. The latter will execute quickly enough (yes, it only recompiles what
you've changed), but the startup time is still annoying enough to want to
batch up edits.

------
yason
You don't have to convince me — you have to convene me.

I'm excited about clang but it's not _that_ 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.

------
mfukar
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..

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

~~~
nitrogen
That is pretty impressive. I use colorgcc to make gcc's messages easier to
spot and sort, and I always thought gcc had the best error messages (better
than MSVC last time I tried it). I might just try clang to see if its messages
are better in all the cases I typically encounter.

------
Aegean
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.

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

------
eordano
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?

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.

~~~
pgbovine
_just because the ui is more user-friendly?_

Those better warnings aren't just due to a simple UI patch ... clang is doing
better and deeper static analysis than gcc in order to even be able to produce
those more intelligent warnings.

~~~
ahn
gcc with the dehydra plugin is doing better and deeper static analysis than
clang.

~~~
Zev
Doesn't dehydra do static analysis for C++ code? In which case, of course it
would do better then clang; clang doesn't even claim to have complete c++
support yet.

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

~~~
malkia
XCode uses gcc & clang (llvm) & llvm-gcc. So what's your point?

~~~
jrockway
"Apple!!111!!", I think.

