Slashdot Mirror
Developing In C/C++? Why You Should Consider Clang Over GCC (dice.com)
Nerval's Lobster writes: The idea with Clang, a compiler front-end for C, C++, Objective-C++, and Objective-C, and LLVM (a compiler infrastructure) is that you can mix the compiler front-end with a targeted back-end and end up with highly portable and efficient compiler. Clang can perform static analysis of your code, and lets you write tools that give you information about a program. Although many developers prefer developing in C/C++ using GCC, developer David Bolton (in a new Dice article) makes an argument for why you should switch to Clang. While GCC is probably still best when it comes to speed, he argues, Clang is improving release by release, and features tools that developers could find useful.
Nope, those still get you modded down. To be modded up, you'll need to be an elf or a hobbit...
Translation: "network tran--I mean speed is a feature that most of our users don't need, so it's not in our development plan"
No. Clang produces faster code. What TFA means is that GCC compiles faster. But if slightly faster compiles are that important, just turn off the optimizer, or buy a faster computer. How much time does a modern developer spend waiting for the compiler to finish? For me, it is less than 1%. Far more important is the better error messages, warnings, and static analysis from Clang. Those save me way more time than the speed of the compiler.
Large applications can take -forever- to compile, even if its not a clean compile.
Many complaints about slow compiles are due to dysfunctional workflow. You should be using precompiled headers, and set up your makefiles for multiple cores. But most importantly, you should be using TDD to develop and debug code outside of the application. So instead of compiling and linking the entire application repeatedly as you track down a bug, you only integrate after all your unit tests are written and passed in isolation.
But, anyway, it isn't clear that Gcc actually compiles faster than Clang. Here are some benchmarks, and the results are mixed. Sometimes Clang is faster, sometimes Gcc is faster. For a large app, they would likely be about even in compile time. But Clang would likely generate better code, and almost certainly generate more helpful errors/warnings/analysis.
I can't see any rational reason to prefer Gcc.
No, LLVM/clang is all about having a superior architecture to GCC, so that a lot of new applications become possible. One of the key ideas is that the optimizer and code generator are libraries with a C++ API. One cool application of this is that you can use the LLVM library to implement a JIT compiler for your interpreted language: you generate the machine code directly into memory (instead of to a file), then execute it.
LLVM has many more developers than GCC, and is evolving and improving more quickly than GCC can. This is because of the licence: it turns out that corporations like Apple are more willing to provide developer resources for this open source project if the licence isn't copyleft. For this particular project, this means that the BSD license is more successful than the GPL. Of course, there are other projects for which the GPL produces better results in the real world.
If you want to make a GPL fork of LLVM just for the pure pleasure of fucking over the original project due their heresy in choosing a license you don't approve of, well, good luck with that.
I have written a truly remarkable program which this sig is too small to contain.
>better error messages, warnings, and static analysis from Clang. Those save me way more time than the speed of the compiler.
This is the truth. Ain't nobody got time to read through a hundred lines of error messages to track down a single bug.
As a simple test, I wrote the following code which has a simple mistake (using an integer instead of an int array in a range-based for loop):
test.cc:
#include
int main() {
int x = 0;
for (int i: x) std::cout constexpr const _Tp* std::end(std::initializer_list)
end(initializer_list __ils) noexcept"
2 lines for a single straightforward error in clang++ 3.7 (with colors even!):
"test2.cc:5:12: error: invalid range expression of type 'int'; no viable 'begin' function available
for (int i: x) std::cout i;"
I currently use g++ with new programmers, and will be switching soon to clang++.
Plus Clang does cool things like interoperate with things like YouCompleteMe to do real time compiling and error message generation for syntax completion in VIM.
And what kind of garbage programmers are you that need to compile the same code multiple times? Write the code correctly the first time and only compile once.
This is because of the licence: it turns out that corporations like Apple are more willing to provide developer resources for this open source project if the licence isn't copyleft.
That's not really true, Apple contributed to GCC for years before LLVM. The problem was that Apple wanted features, and GCC wouldn't allow those features to be built. So finally Apple just gave up and built their own.
This is the rule of running an open source project (and Linus does a really good job of it): give users what they want, or the users will leave.
"First they came for the slanderers and i said nothing."
Apple migrated over to Clang, but they left a bastardized GCC in it's place as a "transition". The preprocessor swears up and down that it's GCC but if you use inline assembler it barfs. So it's basically lying. It's a GCC front end and LLVM back-end, and the solution is to manually install a real GCC in its place (easier than porting the code, easier than ifdef OSX vs Linux, etc). And it's a major pain in the ass for new developers to set up a development environment, and inevitably someone eventually screws up their PATH to pick up the broken compiler...
Anyway screw it. Clang may be ok, but there's production code that assumes GCC, it's cross-platform code so having stability on x86 doesn't necessarily mean anything about all those other CPUs that GCC supports well. Ie, GCC supports ARM, and ARM supports GCC, so if I go to the team and say "hey guys, I'm going to mix things up for a few months and try out a different compiler, things might break unexpectedly but in the long run you might like it, what do you think?" then I won't get positive feedback.
Until there are drawbacks to GCC there's no much reason to change.
Apple, whose most profitable product lines all include ARM chips, has a large compiler team working on Clang and LLVM. Google, which doesn't ship any ARM products, but does have a huge investment in the ARM ecosystem, also employs a lot of people contributing to LLVM. They contributed most of the ARMv8 back end. ARM also has several large teams working on LLVM (I think that they've largely consolidated them now - they used to have separate C, OpenCL-ARM, and OpenCL-Mali teams all working largely independently on LLVM) and is now (as the other poster says) using LLVM for their proprietary toolchain (which is mostly expensive because of the debugging / tracing tools), so they're contributing a lot. There are a lot more ARM developers working on LLVM than clang. IBM has people working on PowerPC support, Imagination Tech on MIPS support. SPARC is largely volunteers these days, but Oracle seems to be killing SPARC as a thing anyone else might care about.
I am TheRaven on Soylent News