LLVM Replaces libstdc++ Library With libc++

[Svartalf]

Speed, diagnostics, size, and not being limited to the GPL universe.

Speed's not there. We've seen that this isn't the case right at the moment. It's got the prospects thereof, but it's not there yet.

Diagnostics are better, yes.

Size? Size??

Not being limited to the GPL universe, I can appreciate and understand- and that's the main reason I'm interested in it along with the potential for better performance in the big picture sense of things- it's just not there yet like you're making it out to be, deanjo.

[Remco]

Nope. Read up on the licensing. You can not add/remove restrictions past what the GPL allows unless you are specifically the license holder. Once you GPL/LGPL something, any upstream providers from your modifications will be licensed under the GPL unless you own the whole thing. If you make it you can dual license it. Anybody that takes up the GPL branch will have code that can only be licensed under the GPL branch.

Yes, the "BSD+" license does not allow for mandatory additional conditions. So it's not compatible with GPL code for which you don't own the copyright. It is compatible in the sense that it is not forbidden by either license to combine the code. A similar license such as the MS-PL, is always GPL-incompatible.

Besides, what you're trying to do is accomplish the GPL there without trying to "restrict" things. Unfortunately, there is a reason that many GPLed projects are flourishing and many of the BSD licensed ones are not. If you ponder for a moment why that might be, you might understand things better. You might not wholly agree with the tenets, but there IS something to it all.

Every license restricts things, except maybe a CC public domain license. BSD imposes 3 conditions on distribution, the GPL numerous. My proposed BSD+ is not nearly as restrictive as the GPL. In addition to the 3 conditions of BSD, it just forces BSD-incompatible licenses such as the GPL to dual license.

[Shining Arcanine]

There's some tests on the mailing list showing it being much faster than libstdc++: 5 seconds versus 22 seconds.

It would be nice if you specified what it is so much faster than it at doing.

[elanthis]

I expect Apple will eventually slap a draconian EULA on the compiler suite

On XCode, maybe They don't own LLVM. All of the LLVM copyrights are owned by the University of Illinois, and patents on contributed code are expected to be released under a license allowing any downstream LLVM modification or distribution to use said patents without royalties.

But hey, why actually check facts or even read the license when you can just make shit up to attack a company you dislike?

Speed's not there. We've seen that this isn't the case right at the moment.

There are two different kinds of speed: runtime speed of compiled code and the speed of compilation. Clang is faster at the latter. It's runtime speed isn't as good as GCC yet, but that's a gap that will narrow and close as LLVM as a whole improves, and LLVM is improving at a rapid pace entirely independently of Clang itself. Remember that LLVM is being used in the graphics driver space these days as well as for other compilers and runtimes.

Diagnostics are better, yes.

Which are fantastic and enough reason as any to junk GCC. And no, GCC cannot be improved, because the maintainers *don't want it to be*. I filed a number of bug reports against vague, ambiguous, and just flat out stupid GCC error messages and diagnostics. All of them were closed with a comment along the lines of, "I know what they mean, new developers should be able to figure out if they aren't idiots."

Size? Size??

Yup. Smaller, cleaner, easier to work on codebase. LLVM and Clang are both joys to hack on, unlike GCC which is a monstrosity of WTF-ness.

Also, there are other reasons that haven't been mentioned. Reasons youc ould have easily found yourself if you spent 5 minutes looking at the Clang website instead of being lazy and using other peoples' equally poorly researched posts as the source of all facts on the project and Apple's motivations. Way to go.

One of the single biggest avantages of Clang is that it is a library, not a program (though it obviously ships with a program that uses the library to provide a complete compiler). Clang as a library makes all kinds of stuff possible that GCC does not. One of the most interesting (and one that Apple is quite interested in) is the ability to use the compiler for code completion and static analysis inside of an IDE (e.g. XCode). The alternatives now pretty much come down to etags (which is a piece of shit, it can't even complete on local variables), incredibly incomplete half-assed parsers that will barf on any moderately interesting use of templates, or simple regex machines that can barely do what etags does. The only interesting alternative that has appeared that even comes close to what Clang can offer for completion is KDevelop's duchains, which are brand spanking new and GPLv3'd (making them totally unsuitable as a library to most corporations). GCC cannot be used as a library, the FSF and RMS refuse to let it be a library, and even the plugin system (which does not provide all of the advantages that GCC-as-a-library would have provided, and which are needed) took years to get approved and a ton of legal wrangling and probably required a gun to be held to RMS' head to get approved.

[Remco]

One of the single biggest avantages of Clang is that it is a library, not a program (though it obviously ships with a program that uses the library to provide a complete compiler). Clang as a library makes all kinds of stuff possible that GCC does not. One of the most interesting (and one that Apple is quite interested in) is the ability to use the compiler for code completion and static analysis inside of an IDE (e.g. XCode). The alternatives now pretty much come down to etags (which is a piece of shit, it can't even complete on local variables), incredibly incomplete half-assed parsers that will barf on any moderately interesting use of templates, or simple regex machines that can barely do what etags does. The only interesting alternative that has appeared that even comes close to what Clang can offer for completion is KDevelop's duchains, which are brand spanking new and GPLv3'd (making them totally unsuitable as a library to most corporations). GCC cannot be used as a library, the FSF and RMS refuse to let it be a library, and even the plugin system (which does not provide all of the advantages that GCC-as-a-library would have provided, and which are needed) took years to get approved and a ton of legal wrangling and probably required a gun to be held to RMS' head to get approved.

I read that the plugin system for GCC allows it to be used for code completion and static analysis, and pretty much anything that LLVM does. Your decidedly anti-GCC rant doesn't quite convince me otherwise.

[XorEaxEax]

Speed, diagnostics, size, and not being limited to the GPL universe.

Speed - nope, GCC still outperforms llvm overall. Diagnostics, YES! llvm/clang has the best diagnostics/error messages I've seen in a compiler. Size, nope not last I checked here : http://embed.cs.utah.edu/embarrassing/

[edvin]

don't forget refactoring!

[XorEaxEax]

On XCode, maybe They don't own LLVM. All of the LLVM copyrights are owned by the University of Illinois, and patents on contributed code are expected to be released under a license allowing any downstream LLVM modification or distribution to use said patents without royalties.

No, but they have their own developers in Apple who working on it apart from the *public* guys they hired like Chris Lattner (are there any others?) and these in-house developments does not need to be released back to the project. Other things like LTO (link time optimization) in llvm is still only available for the darwin platform while in GCC it's available for all versions.

Which are fantastic and enough reason as any to junk GCC.

Well, honestly it's way better than all other compilers, msvc has pretty crappy diagnostics aswell from what I remember.

And no, GCC cannot be improved, because the maintainers *don't want it to be*.

Bullshit, the maintainers have stated many times on the mailing lists that they are working on improving this aspect. However since it's developing even faster than LLVM is, there's only so much they can do. Currently implementing polyhedral optimizations through graphite/cloog seems to be the next big thing on the agenda. Improving the diagnostics to the level of LLVM will be a great undertaking so it will likely have to wait (in other words, I'm not holding my breath).

GCC cannot be used as a library, the FSF and RMS refuse to let it be a library, and even the plugin system (which does not provide all of the advantages that GCC-as-a-library would have provided, and which are needed) took years to get approved and a ton of legal wrangling and probably required a gun to be held to RMS' head to get approved.

Bullshit again, RMS has no call on what GCC does or does not do. All the decision-making is done by the GCC steering commitee, consisting of full-time employed GCC developers from companies such as IBM, Red Hat, Novell etc. The voices against a plugin system was that many GCC developers feel that it means more and more companies will just use GCC as a front-end for their own proprietary code generators/optimizers etc and not contribute those back to GCC. And personally I can understand that opinion. But it can also lead to good things like for instance the open dragonegg plugin.

[smitty3268]

According to the mailing list, it appears the main reasons for this are:

1. Apple engineers aren't allowed to work on GPL3 code, which means their only choices were forking libstdc++ 4.2, picking up another 3rd party solution that is dead (like apache), or creating their own from scratch. That's why all the comparison's are against GCC4.2, because apple doesn't allow the use of anything newer. Also, the c++0x modifications required would be extensive, to the point where starting from scratch made sense.

2. They believe they can make improvements by breaking ABI compatibility, something which the libstdc++ folks would probably not allow.

[Happybob]

One of the most interesting (and one that Apple is quite interested in) is the ability to use the compiler for code completion and static analysis inside of an IDE (e.g. XCode). The alternatives now pretty much come down to etags (which is a piece of shit, it can't even complete on local variables), incredibly incomplete half-assed parsers that will barf on any moderately interesting use of templates, or simple regex machines that can barely do what etags does. The only interesting alternative that has appeared that even comes close to what Clang can offer for completion is KDevelop's duchains, which are brand spanking new and GPLv3'd (making them totally unsuitable as a library to most corporations).

Maybe I am lucky, but I have been using Netbeans 6.8 for C++ development, and its been eating stl, gtkmm, and even boost templates for breakfast. Before 6.8 was a different story, but it has really matured, in my opinion. I'm not saying it wouldn't be nice if the c++ front end would help out a bit, but its entirely possible to get good code completion with GCC. As a bonus, Netbeans does refactoring too!
While people are excited about the simplicity of the clang and llvm code base, it doesn't generate as fast of code as GCC. I haven't looked at llvm, clang, or GCC source, but optimization tends to follow the law of diminishing returns. I'm willing to bet that llvm's source will have to get a lot more complicated to close the last mile and catch up with GCC produced binaries.
Oh, and I don't trust Apple. At all...