Among other reasons, I'd guess this is Apple's attempt at modernization. The GCC/libc/libstdc++ codebase has been around for ages, and has accumulated cruft. Starting from scratch isn't always a solution, but in cases like this I think it can be.
Modernizing the compiler (via clang/LLVM) is a great step forward, but modernizing the C++ libraries to take advantage of the new compiler infrastructure is a sensible step 2. If they can in fact speed up compilation speed and memory requirements (both at compile-time and run-time), as well as providing link-time and run-time optimization, it could be a big win, especially for large C++ projects (such as Mozilla, KDE, Qt, etc.).
I would imagine a lot of it involves improving xcode by using the same code for compiler and IDE. GPL2 or GPL3 really doesn't make much of a difference in this regard.
Although the GPL3 question comes up with the non-inclusion of a newer version of Samba in OS X Server. This is making it hard / impossible to add Win 7 to a network with a OS X Server PDC.
I merely glanced at bits of the code without diving into the implementation that much, but my high-level thoughts:
+ I love the "synopsis" header in front of all the classes.
+ I find the style horrible, but still more readable than the SGI-based STL headers. This is a very good thing.
+ Only one developer currently? I wonder how many bugs are yet to be found in this code. Making it ABI-compatible with libstdc++ should make the "swap it in, does it crash?" test very easy.
Could someone explain: As a person who uses Apple products but doesn't code, what does this mean for me? Is Apple already using this compiler with OS X? Does it mean faster and smaller binaries down the line?
Or is it mostly cool stuff for coders, but mostly transparent for end-users?
Its in use for some products in Snow Leopard; Xcode, OpenGL, (and, I believe) OpenCL and Automator are built with Clang.
Or is it mostly cool stuff for coders, but mostly transparent for end-users?
Mostly, this. However, the cool things it gives are subtly passed onto the user. For example, LLVM and Clang have a nice static analyzer to help developers find and fix memory leaks. There are other optimizations (for the size of the binary and speed of the program being run) that LLVM is working on, but they're not ready for primetime yet (or weren't, the last time I looked).
10 comments
[ 3.4 ms ] story [ 39.9 ms ] threadModernizing the compiler (via clang/LLVM) is a great step forward, but modernizing the C++ libraries to take advantage of the new compiler infrastructure is a sensible step 2. If they can in fact speed up compilation speed and memory requirements (both at compile-time and run-time), as well as providing link-time and run-time optimization, it could be a big win, especially for large C++ projects (such as Mozilla, KDE, Qt, etc.).
Although the GPL3 question comes up with the non-inclusion of a newer version of Samba in OS X Server. This is making it hard / impossible to add Win 7 to a network with a OS X Server PDC.
In this scenario, they want to be able to ship an XCode and iPhoo SDK without having to distribute the source to their code generator.
+ I love the "synopsis" header in front of all the classes.
+ I find the style horrible, but still more readable than the SGI-based STL headers. This is a very good thing.
+ Only one developer currently? I wonder how many bugs are yet to be found in this code. Making it ABI-compatible with libstdc++ should make the "swap it in, does it crash?" test very easy.
Or is it mostly cool stuff for coders, but mostly transparent for end-users?
Its in use for some products in Snow Leopard; Xcode, OpenGL, (and, I believe) OpenCL and Automator are built with Clang.
Or is it mostly cool stuff for coders, but mostly transparent for end-users?
Mostly, this. However, the cool things it gives are subtly passed onto the user. For example, LLVM and Clang have a nice static analyzer to help developers find and fix memory leaks. There are other optimizations (for the size of the binary and speed of the program being run) that LLVM is working on, but they're not ready for primetime yet (or weren't, the last time I looked).