Big step, congratulations to everyone who worked on it. When I get some more time I need to look into the code in those projects. It's too bad that they chose to use C++ (as opposed to C) to implement it though (yech, personal preference).
How can you tell? Did you work on it for a few months or you can just browse the SVN and notice it's well designed? I look and all I see at first is indentation style and directory organization.
If all you noticed from seriously looking through the source is that it is well indented and well organized, you're probably not an experienced enough C++ programmer to evaluate the merits (no offense intended).
One probably couldn't by merely looking at it. Reading it with the specific intent to understand it, on the other hand, can make design intent pretty clear. (One would hope that the structure of the program is at least homomorphic to the intended design, if not isomorphic.)
It's truly excellently written C++ code, and they don't go nuts with fancy C++ voodoo template meta-trans-factory-programming tricks or whatnot. And have you seen what happens when you write a huge compiler in C? This: http://gcc.gnu.org/wiki/reload And I don't think you can reasonably argue that GCC's hackers are sub-par either. ;-)
Language features for abstraction and encapsulation are pretty important for something that huge.
It's really not the age or resources that hamper it (from experience hacking it). Well, OK, the age does matter -- but only because it's C. It wouldn't have been so bad if they didn't have to reinvent basic things. GCC has its own garbage collector, a set of bizzare hacks to replace inheritance, amongst other atrocities. None of these have to do with resource constraints, and nearly all have to do with the low-level nature of C.
Why do a compiler in C at all? I mean, why should a low-level systems language (that values speed above everything) be particularly suited to transforming programs from one language into another?
Because this allows you to compile in places and times where a language with more suitability towards compilation but heavier time or memory needs would be unsuitable.
One example that pops to mind is shader programs on a GPU.
After doing application-level programming in C for a while at a job, I learned to re-appreciate some of the abstractions that C++ gives you that you have to code by hand in C. Once you get used to the ridiculous compile errors and slow compilation times, isn't it nice to have access to a built-in string library and efficient data structures? To not have to roll your own implementation of a v-table and inheritance if you want OO? To be able to do compile-time generic programming where the compiler can more easily do things like function inlining?
I'm no longer certain which I consider is the better language to code in overall. I've heard the C++ hate from Yossi Kreinin, Linus Torvalds, Steve Yegge, and other high profile people, and I've experienced the pain and misery of trying to understand and use its more complex features myself, but in the end, for most applications are you really better off sticking with C than using a "tasteful subset of C++" like the LLVM team does?
I wish someone would publish this "tasteful subset of C++," kind of like Douglas Crockford's Javascript: The Good Parts. Then I could just learn that and skip all the crazy template shit.
This is fantastic. My main gripe with C++ in non-system code is that there are too many features which complicate the code base and should never be used. This seems like great guidelines and a good subset.
I've always hated C++ as a language syntax, but I'm coming around. rubinus, llvm, and mongo all use it and their codebases are really well built. So maybe the language isnt so bad after all, as long as you have geniuses using it.
It's not so much about having geniuses coding in it, it that when you do use it, you use it to make conceptually elegant code. When I work in C++, I simply do not use templates, because I find the make the code impossible to grok - the complexity can overwhelm you (let alone a new developer unfamiliar with a given C++ code base).
Treat C++ like Ruby, and try to use it to make beautiful, and elegant code. That's where it shine, IMHO.
It would be awesome if there were some sort of Trusting-Trust-style "telomeres" encoded into the resultant binary, so that C and C' and C'' would all work identically, but C'''''''''' would suddenly produce different outputs.
He means taking the source code for the compiler and running it through the compiler, then taking the same source code and running it through the resulting compiler, etc. Same source, new binaries every time.
Yes. I know "Trusting trust". And the backdoor will be in the original source code, and after it has passed into the binary you get rid of it in the source.
Clang, a new compiler based on LLVM (http://llvm.org/), designed to be faster and more extensible than GCC, is now able to build its own source tree rather than relying on another compiler. This means that the compiler supports a sizable chunk of C/C++ language features.
C programmers often use the free GCC (GNU compiler collection) to compile their programs. clang is a new open source C compiler that may be better for some people because it has a different licence, will be faster in certain circumstances and may give better error messages. The significant milestone the clang project has reached is the ability to sucessfully compile a very large quantity of C code.
The changes due to GPLv3 (non-discriminatory patent licence etc.) seem to be incompatible with the interests of BSD people [1] as well as perhaps Apple, who is the main sponsor.
LLVM is designed to be more than just a compiler. It's different stages can be used separately by other code, making it well suited for building things like static analysis tools. Apple (sponsor and de facto leader of LLVM) has been taking advantage of this to integrate clang-based static analysis into XCode, the proprietary IDE that ships with Mac OS X. Even if GCC had a clean enough architecture to be used this way, the licensing restrictions would force all of XCode to be open-sourced.
Clang and LLVM take a library based approach. They're designed so that tools that need to work with C/C++/Objective-C can simply link Clang.
GCC was never designed to do this, and even if it were, it's under the GPL and not the LGPL, which makes it unsuitable for linking as a library in non-GPL'd code. In contrast LLVM/Clang has a BSD-like licence.
To add, the use of the less restrictive license allows the creation of tools using clang like a library. For example, you can now use the same parser the compiler is using to do syntax highlighting or refactoring. This will allow both commercial / non-commercial interests to build tools that do interesting things without having to build a parallel infrastructure.
As I understand it, one thing LLVM can do that GCC can't is run-time compilation and optimization: generating code on the fly and compiling it to run at native speeds, maybe also profiling several different versions and picking the best. This is only possible if you have significant chunks of a compiler built into your application. If you were to attempt the same with GCC, your application would need to be GPLed.
Wait does this mean that LLVM supports C++ well now? Last time I checked at WWDC, it had great C and Objective-C support, but C++ was hardly there. It would be great if Xcode can add support for all of the awesome refactoring and static analysis that Objective-C can currently do in C++ now!
In my opinion, I believe llvm-g++ is a more promising approach to supporting C++. C++ is an incredibly difficult language to parse, so why not re-use work that has already been done?
Useful error messages. Even in C gcc is lacking, let alone C++, and I'd imagine that fixing this in gcc wouldn't be/have been much easier than writing clang.
Because g++ has its own problems that won't be solved by switching backends, like unclear diagnostics. Then there's the license issue, which can be important for some. Clang is also built as a library, so you can link to it and JIT c-code at runtime.
45 comments
[ 4.1 ms ] story [ 105 ms ] threadIf all you noticed from seriously looking through the source is that it is well indented and well organized, you're probably not an experienced enough C++ programmer to evaluate the merits (no offense intended).
How can you "infer" the design only by looking at a pile of C++?
Language features for abstraction and encapsulation are pretty important for something that huge.
GCC also has a perennial problem attracting and managing developers, which LLVM seems to have avoided.
One example that pops to mind is shader programs on a GPU.
I'm no longer certain which I consider is the better language to code in overall. I've heard the C++ hate from Yossi Kreinin, Linus Torvalds, Steve Yegge, and other high profile people, and I've experienced the pain and misery of trying to understand and use its more complex features myself, but in the end, for most applications are you really better off sticking with C than using a "tasteful subset of C++" like the LLVM team does?
http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
Too bad it assumes knowledge of C++. I hope I can still follow it with my limited C++ knowledge.
Treat C++ like Ruby, and try to use it to make beautiful, and elegant code. That's where it shine, IMHO.
http://cm.bell-labs.com/who/ken/trust.html
(Edit: C++ as well as C)
In which manner does the GCC license restrict the user in a problematic way? (well, except GPL's distribution restrictions I suppose.)
[1] http://wiki.freebsd.org/BuildingFreeBSDWithClang
GCC was never designed to do this, and even if it were, it's under the GPL and not the LGPL, which makes it unsuitable for linking as a library in non-GPL'd code. In contrast LLVM/Clang has a BSD-like licence.