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.

6 of 255 comments (clear)

  1. Translation by RightwingNutjob · · Score: 2, Insightful

    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

    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"

    1. Re:Translation by Darinbob · · Score: 4, Insightful

      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.

    2. Re:Translation by TheRaven64 · · Score: 4, Insightful

      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
    3. Re:Translation by Anonymous Coward · · Score: 2, Insightful

      1) Long term Freedom. The importance of which can not and should not be understated.

      Except gcc doesn't give you that. The FSF keeps changing the goalposts on what constitutes "free" software (see GPLv2 vs GPLv3, for instance), and every time they do it, they lose developers who can no longer adapt to their ideology. Clang is FREE. Sure, someone might fork it, someone might embrace&extend it, this does not mean I will in the future be unable to use the Clang code I have on my hard-drive right now. And it's a compiler. It compiles code, to a standard. Lock-in is not an issue.

      You are pushing a concept of theoretical freedom which doesn't even give people the practical freedoms they actually need, against a different concept of freedom which is for all practical considerations completely unencumbered.

      Choose your compiler based on ideology if you like. The computer industry wasn't created on that basis, and doesn't work on that basis.

  2. Or compile on everything by Anonymous Coward · · Score: 3, Insightful

    Compile in both. And visual studio too if possible. Enable all warnings. They are all good at identifying different categories of problems and code that compiles cleanly under multiple compilers will prove easier to maintain.

  3. Re:License by Anonymous Coward · · Score: 1, Insightful

    JIT compiled binaries are no good for the end user. For fucks sake, distribute native binaries for your shit.