Developing in C/C++? Consider Clang


In order to better understand Clang, a compiler front-end for C, C++, Objective-C++, and Objective-C, you have to start with the LLVM project. LLVM is short for Low-Level Virtual Machine; it’s an intermediate compiler language (i.e., LLVM IR) similar in concept to bytecode or .il.

Clang compiles the C/C++/Objective-C source code and outputs LLVM IR instructions, which are low-level RISC-like. The LLVM backend then generates the appropriate machine code for the targeted processor and system (which could include any X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, or XCore system).

Although the LLVM infrastructure is open-source, the U.S. National Science Foundation, Apple, the University of Illinois, AutoESL Design Technologies, and others have all sponsored its development. Apple in particular has funded a lot of development since 2005, with Clang replacing GCC for iOS and Mac OS development in 2011.

The idea with Clang and LLVM is that you can mix the compiler front-end with a targeted back-end and end up with highly portable and efficient compiler. Front-end compilers exist for C, C++, Common Lisp, ActionScript, Ada, D, Fortran, OpenGL Shading Language, Go, Haskell, Java bytecode, Julia, Objective-C, Swift, Python, R, Ruby, Rust, Scala, C# and Lua. Clang itself was open-sourced in 2007.

What Makes Clang Better?

It can perform static analysis of your code, whether in C, C++ or Objective-C. This functionality is built into the Xcode version that runs on the Mac, with instructions provided to build the static analyzer on other platforms.

Static analysis is a technique whereby the program is read and ‘understood’ to the point where obvious bugs are automatically detected, such as dead code, memory leaks, double-frees, bad pointer references, and other such conditions.

Write Clang Tools

Clang lets you write tools that give you information about a program. There are three ways to do this:

  • Use LibCLang, a high-level C interface to Clang. This should be your first port of call, as it lets you access Clang from languages other than C++, as well as walk through the AST using a cursor. (AST is short for Abstract syntax tree, and is the output of the front end before generating the LLVM IR code that is used by the backend. Here’s a useful introduction to the Clang AST.)
  • You can write plugins for Clang to modify the compile process.
  • The third way is to use LibTooling, a C++ interface that lets you write standalone tools.

And here’s a useful set of external Clang examples:

C++ 14 and C++ 17/1z

Clang has offered C++ 14 features for over a year, along with some C++ 17 (also called 1z) features; check out their current status. Note that it’s had C99 features since version 2.9. If you want to see 1z support in GCC, look here. Current release versions are GCC 5.2 and 4.9.3 with 6.0 in development.

Cygwin and Mingw

If you want to use GCC on windows, you have to use Cygwin or possibly Mingw. Cygwin and Mingw are command-line tools that let you run Unix tools on Windows, altered and recompiled for Windows.

The main difference between Cygwin and Mingw is that Cygwin includes Posix support. Posix is a set of standards for Unix compatibility. (Clang can be used from within Visual Studio and does not necessarily need Cygwin or Mingw.)


If you develop in C/C++ using GCC, you’re probably wondering if you should switch to Clang. While GCC is probably still best when it comes to speed, Clang is improving release by release. While I’d put my money on Clang for the long term, stick with GCC unless you have a compelling reason to do so otherwise.

6 Responses to “Developing in C/C++? Consider Clang”

  1. Correct answer is you should not choose clang or gcc but both. Due to the differences in the compliers both will unearth different coding errors.

    Static analysis has been gcc plugins for a long time but no one is doing the work to get them mainlined as much as they should.

    Thing to remember gcc speed is improving release to release as well.

    The difference is gcc plugin have to be GPL licensed. But LLVM plugins can be closed source.

    Just because llvm has visual studio support this does not mean Microsoft has not extended the one they are using. and apple has there own LLVM fork. Yes MSVS and x-code llvm is extended so might be a rude surprise when you take your code cross platform.

    This is something about gcc in mingw and cygwin those the complier is the mainline one. One of the main reason to go LLVM is the means to extend it and not have to release the code.

    Just because something is open source does not mean it cannot stab you in the back. Higher permissive licenses open source have very particular traps just like copyleft licenses like GPL has. If you goal is cross platform with a complier dependable cross platform the answer is GCC because its license forbids the complier been extended in secret. So a platform issue caused by a code modification in GCC you can see what it is and port it if you wish. LLVM permissive license means the code modification could be trade secret.
    Yes from visual studio 2010 it been possible to use mingw from visual studio. Problem visual studio non conformance comes back and bites. llvm used in visual studio should make it nicer when building mingw projects from visual studio.

    The problem with this post is you covered all llvm upsides and missed the downsides and worse overstated features.

    There is a final thing to be aware of. llvm and gcc running under Linux/BSD/.OS X based is faster than running under Windows. So changing platform and not using visual studio to build gives bigger build performance gains than changing complier.

  2. thurizas

    a few comments:

    (1) all compiler have a front-end (mostly a lexical analyzer and a parser) that emit some form of intermediate representation. This intermediate representation is then passed to the back end for optimization, analysis and finally it is emitted as assembly. Typically the front-ends are language specific and the back-ends are platform specific. Your first few paragraphs make it seem as if Clang/LLVM is the first framework to do this.

    If I recall correctly there have been patches to the gcc source code to allow access to gcc’s AST. Again, gaining access to the AST to allow analysis is nothing really new.

    On Windows I use mingw64 as a compiler. It is a fully native port of gcc to a windows platform (meaning that unlike Cygwin, it does not depend on a third party DLL). It works very well, in fact a good deal of my C/C++ programming on Windows is done using NtEmacs as an editor, mingw64 as my compiler and gdb as my debugger. Works great, and less hassle then visual studio at times. Your final paragraph, in my opinion, paints a fairly dim view of using other tools on Windows.

  3. I think targetting a specific compiler while coding, is the wrong approach.

    I usually make sure my code works at least with gcc -and- clang. And if possible also MSVC. Getting the bonus of different sets of compiler warnings to look after.

  4. Nice article: too bad clang++ still wont let me do exceptions when targeting 32Bit windows from 64Bit linux…

    Something i’ve had working for ages with my gcc toolchain…

    I really want clang… shaves a full minute of my build time 🙁

  5. Cygwin and Mingw still lack much in the 64bit STL department. It’s even safe to say your better off just using Visual Studio, 64 bit instruction is practically crucial in this day and age. And GNU is known to favor Linux over Windows.