Comment: The speed of Clang Development

Nicola left this comment on “The Growth of C++11 Support“:

“It’s interesting to see how far behind Clang starts in comparison to the others, and that it ends up in a close dance with GCC on the way to full C++11 support.”

Yeah, but the little detail is that the first version of clang that you listed, 2.8, probably didn’t support C++ at all. Clang is such a young project after all. The first versions supported C and Objective-C (that were the main interests for Apple which at the time was the main and only real contributor). Then they started the development of C++ support and it took them less than two years to implement the full C++03 standard! This chart really doesn’t express how fast clang developers have worked to support this very complex language.

Between http://en.wikipedia.org/wiki/Clang and http://llvm.org/releases/ it appears that Clang was able to compile all of Boost as of (or soon thereafter) version 2.7 — I think it’s fair to say that C++03 support was pretty robust as of version 2.8.

This chart illustrate exactly how quickly C++11 support has been added to Clang: starting behind the others, Clang was second to have full C++11 support, and (iirc) only second because of the timing of release cycles. The same pattern is clear in the other charts: the rate that modern C++ support has been added to Clang has consistently outstripped that of the competition.

Comment: “it’s not just about what the compiler supports…”

Eric left this comment on “The Growth of Modern C++ Support“:

It looks like from the chart that Visual Studio is behind Clang, which you would think would put XCode on the Mac ahead, but there is also this issue that frankly I don’t understand: On the Mac, libc++ is a feature of the *operating system* that is apparently not updated. So, on the Mac, if you want to support a couple releases back, your modern C++ support is limited to what the furthest back version you plan to run on supports. OTOH, Microsoft has vcredist, Visual C++ redistributables, that can exist side-by-side on any version of the operating system. So your use of modern C++ features is not limited by the operating system.

I guess my point is, it’s not just about what the compiler supports. It’s about what the machine that you want your software to run on supports.

It seems most unfortunate, if I understand this issue correctly, that Apple would tie the dev tools so tightly to the OS.

The relationship between compilers, standard libraries, and operating systems is complex. It is very easy to end up with an explosion of combinations that is (effectively) impossible for vendors to support, and for application & library developers to create executables that no one but they can use (there are endless stories about the “joys” of shipping binaries for Linux, for example).

To mitigate this, operating system and commercial toolchain releases are often conservative in how they advance the state of the art in their own releases. As you point out, application developers have to take extra care if they want to ensure that the code they are writing will work for all the platforms they are targeting.

The charts demonstrate the level of support available in particular compiler versions, and not the level of support available to end users of any particular platform. In practice, operating systems & platform toolchains will always lag toolchain releases (for OSX, it seems like you could work out exactly how much lag with information like this: http://en.wikipedia.org/wiki/Xcode. I couldn’t find a comparable table for Linux distributions).

As a cross-platform game developer, I do find it frustrating to be able to use only the least of the features provided by the set of toolchains needed for a particular project. On the other hand, it’s rarely a functional limitation. Typically it means not having access to convenience features and tool improvements that contribute to efficiency/productivity.