LLVM Clang Compiler Now C++11 Feature Complete

An anonymous reader writes "With the latest development work on Clang ahead of the release of LLVM version 3.3, Clang is now C++11 feature complete. The last remaining features of the ISO C++11 feature specification have been implemented. C++11 support for GCC is also more or less complete."

Comments

Thank you, Apple!

[Anonymous Coward]

Regardless of what you may personally think about Apple, they have made some very valuable contributions to LLVM and Clang. So I just want to say, thank you, Apple. Your generosity has touched my heart, and made C++11 a reality.

Re:Thank you, Apple!

[Tough Love]

What makes you think it has anything to do with generosity?

Re:Thank you, Apple!

[BasilBrush]

Please do share your crackpot theory of why Apple were evil to release Clang as open source. I could do with a laugh.

Re:Thank you, Apple!

[_merlin]

Oh I don't think anyone thinks it's evil, just that it's pure self-interest rather than generosity. GCC's phenomenal popularity has led to its maintainers growing massive egos and behaving like total cunts. Bugs are introduced faster than Red Hat and Apple can get patches for them accepted, and they have a nasty habit of not looking at bug reports, then closing them due to inactivity without actually fixing them. Apple probably likes the idea of being able to make closed-source forks of a compiler, too. Nothing evil, but not really generous either.

Re:Thank you, Apple!

[Anonymous Coward]

I don't think it's anything like that. If clang doesn't do what Apple needs, and Apple modifies clang because of it, it's probably both in the community's and in Apple's best interests for those changes not to remain local to Apple's private version of clang, although the specifics depend on how invasive those changes are. Generous would be if it doesn't benefit Apple, but does benefit the community. Evil would be if it benefits Apple, but hurts the community. This is neither.

Re:Thank you, Apple!

[Anonymous Coward]

Please do share your crackpot theory of why Apple were evil to release Clang as open source. I could do with a laugh.

Please do share your crackpot theory of where the GP used the word "evil" in relation to Apple.

Re:Thank you, Apple!

[rtfa-troll]

What makes you think it has anything to do with generosity?

Assuming he's not a shill (in which case the answer would be his pay check), propaganda, stupidity and things like ESR's essay saying that the GPL is no longer needed.

For a time, up to a few years ago it looked like programmers could become truly independent of the companies they work directly for, a bit like graphic artists, shop keepers, SAP specialists and so on. The basis of this would be that most companies would use the same FOSS software, sharing that from company to company. The vast efficiency gain would have been shared between the (no longer) customers of big IT companies like Microsoft and the programmers. Software would start to advance at the rate that benefitted its users, not the people stealing from them.

Apple, and to a large extent Google, have come with new business models where they take the output of that process and rebundle it in a way which allows them to avoid sharing the key features which differentiate their products. In Google's case by keeping the most important bits on servers where you can't access it. In Apple's case by adding proprietary GUIs and other features which mean that nobody else can the free stuff and compete with them.

LLVM is one of their key tools in trying to leverage that. This is done for profit, mostly by taking money out of the pockets of people like Slashdotters. It is a tool in ensuring they will be able to build developer environments where they take your source code and hide it from you. It is not a coincidence that we keep getting stories about there being lots of non-GPL software coming out etc. The shills want us to give them everything we have for free and have no need to return to the community.

Correct answer: License under the AGPLv3 whenever you can and only back off to the GPL or LGPL, let alone MIT licenses when someone gives you a really compelling benefit for doing so.

Re:Thank you, Apple!

[Anonymous Coward]

Uh, oh -- a bit touchy today are we?

Re:Thank you, Apple!

[TheRaven64]

It's not a question of good vs evil, it's a question of generosity vs self interest. The grandparent was claiming that Apple open sourced clang out of generosity. This is not the case, they did so because it is in their best interests to do so. These days, the two biggest contributors to LLVM and Clang are likely Apple and Google, but companies like ARM, Qualcomm, MIPS (or whoever owns them this week), TI, Adobe, and a load of smaller contributors all contribute and Apple gets all of these for free. Some of those contributions aren't necessarily useful to Apple (for example, the MIPS back end), but a lot are (for example, the autovectorisation support).

Re:Thank you, Apple!

[Anonymous Coward]

It has long been accepted fact that GPL does hurt open source in the long run.

Re:Thank you, Apple!

[rtfa-troll]

It has long been accepted fact that GPL does hurt open source in the long run.

Normally I ignore obviously wrong unmoderated AC posts, however this one is an interesting example. Why would a non logged in user see my post, which is still at normal level, so quickly as to be the first person to comment? Remember that posts for logged out users sort according to moderation not time of posting. Even if this had already reached the static page it would be way down at the bottom. Why the "long been accepted fact" rather than something like a link to an argument or "it seems pretty clear to me". Again the answer is simple. Properly logged in shills astroturfing to make this look like a common argument and mostly posting as AC to avoid taking hits on their real accounts and/or being traced later.

There may be a fair number of people who agree with this position, but it's never come close to being "accepted". In fact, anyone who knows the history of computing knows that originally most software was distributed under completely free licenses. That world was completely destroyed by proprietary software in the '70s and '80s and it was only the arrival of the GPL and GCC in particular which allowed, for example, the BSD operating systems to become self hosting and self sustaining.

Think about it. Why are these people trying to persuade you of something which is against your interests? If you release your software under the BSD license you can never put it back under the AGPL. The opposite is never true. If there turns out to be a true benefit later, you can always opt to change over. The answer is simple. They want something from you. Make sure you get something in return before you give it out. Money maybe; better benefit for your and your children's future.

Re:Thank you, Apple!

[Anonymous Coward]

Apply only contributes because then they don't have to spend effort every time they want to merge their private fork with the upstream. Nothing else. If the LLVM/Clang developers had have more forethought and picked GPL they could have forced Apple though court to release those changes.

Re:Thank you, Apple!

[Anonymous Coward]

You mean this private fork?
http://www.opensource.apple.com/source/clang/clang-425.0.24/

Take hint retard there is no private fork of clang at apple what so ever.

Re:Thank you, Apple!

[kthreadd]

There may be a fair number of people who agree with this position, but it's never come close to being "accepted". In fact, anyone who knows the history of computing knows that originally most software was distributed under completely free licenses. That world was completely destroyed by proprietary software in the '70s and '80s and it was only the arrival of the GPL and GCC in particular which allowed, for example, the BSD operating systems to become self hosting and self sustaining.

Very true, BSD has a lot to thank GCC and the GNU project for. And not just BSD. It doesn't really matter which UNIX flavor you install today, most of them include or optionally provide the GNU userland.

Think about it. Why are these people trying to persuade you of something which is against your interests?

Which interests?

If you release your software under the BSD license you can never put it back under the AGPL. The opposite is never true. If there turns out to be a true benefit later, you can always opt to change over. The answer is simple. They want something from you. Make sure you get something in return before you give it out. Money maybe; better benefit for your and your children's future.

I'm not an expert on either of those licenses, but do you really mean that you can't change BSD to AGPL? In that case that's news to me.

Re:Thank you, Apple!

[Anonymous Coward]

Of course there's no private fork on the web, then it wouldn't be very private.

Re:Thank you, Apple!

[Em Adespoton]

If the LLVM/Clang developers had have more forethought and picked GPL they could have forced Apple though court to release those changes.

If the LLVM/Clang developers had picked GPL, Apple would have had virtually no incentive to switch to LLVM/Clang from GCC. The result? We'd be having this discussion about some other compiler with a permissive license, and almost nobody would have heard of LLVM.

Re:Thank you, Apple!

[ShanghaiBill]

just that it's pure self-interest rather than generosity.

So what? As long as good things get done, what difference does it make what the motivations are? If anything, selfish motivations are superior because they are more sustainable. I hope that other companies look at Apple's example, and come to understand that participation in Open Source is in their self interest too.

Re:Thank you, Apple!

[SuperKendall]

Apply only contributes because then they don't have to spend effort every time they want to merge their private fork with the upstream.

Go to WWDC and talk with the actual developers working on it. That's not the case at all.

It *IS* true that Apple gains from less merging work by contributing code. But be realistic; there are real coders working on these things at Apple and just like ANY coder, they are happier the more people get to use their work. Developers that work at Apple are not mustache-twilrling villains; they are coders like you or I, just as motivated by people in the compiler community appreciating effort as they are by an Apple paycheck.

Re:Thank you, Apple!

[BasilBrush]

Of course there's no private fork on the web, then it wouldn't be very private.

If it were so private they weren't distributing the binary, they wouldn't have to distribute the source with GPL either.

And there's no secret to what clang they are distributing:

clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix

Re:Thank you, Apple!

[BasilBrush]

If the LLVM/Clang developers had have more forethought and picked GPL they could have forced Apple though court to release those changes.

Clang was created by Apple. Why would they want to take themselves to court?

Re:Thank you, Apple!

[BasilBrush]

Oh I don't think anyone thinks it's evil, just that it's pure self-interest rather than generosity.

Which is the same reason anyone that contributes to open-source does it. Self-interest. So why are Apple being singled out?

Re:Thank you, Apple!

[Anonymous Coward]

Not logged in and your post is near the top of the page. PS: you sound like a paranoid nutter. Pretty funny for someone with "troll" in their username.

Re:Thank you, Apple!

[Microlith]

Because the AC in the initial post in this thread did.

Re:Thank you, Apple!

[Anonymous Coward]

While Apple does have one walled garden product with iOS, at least Mac OS X has an open source kernel (Darwin)! Now, which operating systems are closed again? Who favors open source solutions like CUPS, WebKit etc?

Re:Thank you, Apple!

[UnknowingFool]

Apple, and to a large extent Google, have come with new business models where they take the output of that process and rebundle it in a way which allows them to avoid sharing the key features which differentiate their products.

Um what? Clang is open source. WebKit was open sourced by Apple. Under the GPL they are only obligated to release modifications to the original KHTML base code. They are under no obiligations to release JavascriptCore or WebCore but they did. Apple didn't have to hire Michael Sweet and have him keep developing cups.

In Apple's case by adding proprietary GUIs and other features which mean that nobody else can the free stuff and compete with them.

It means you can't use their stuff which they want to keep proprietary. But you are free to compete to develop your own. Also under the BSD license which OS X is derived, Apple doesn't even have to release Darwin but they do.

LLVM is one of their key tools in trying to leverage that. This is done for profit, mostly by taking money out of the pockets of people like Slashdotters. It is a tool in ensuring they will be able to build developer environments where they take your source code and hide it from you.

Again, what? Clang is open source and Apple is a major contributor. LLVM is open source and Apple is a major contributor. LLVM was released under a BSD style license long before Apple was a contributor.

It is not a coincidence that we keep getting stories about there being lots of non-GPL software coming out etc. The shills want us to give them everything we have for free and have no need to return to the community.

Again, what? Do you even look at this page?

Correct answer: License under the AGPLv3 whenever you can and only back off to the GPL or LGPL, let alone MIT licenses when someone gives you a really compelling benefit for doing so.

And who are you to dictate to the authors what license they pick? LLVM picked a BSD license long before Apple was involved. NeXT used the same type of license long before Apple purchased them. Apple cannot change the license differently than the authors intended.

Re:Thank you, Apple!

[cheesybagel]

Apple supports OpenCL compilation using clang. I never saw any mention of this being open sourced. It seems all clang support for OpenCL has been developed somewhere else.

Re:Thank you, Apple!

[cheesybagel]

GPL sure. But had they picked LGPL it would probably have been accepted as well since most of the interest is in the hooks it provides for IDEs.

Re:Thank you, Apple!

[cheesybagel]

Clang is based on LLVM which was developed in an academic environment. WebKit is based on KHTML. Sure Apple could close source their code further but then they would have to keep updating their branch to match the open fork. That takes a non-insignificant amount of time and effort.

Over time people will realize why a compiler shouldn't be BSD licensed. There is a reason why other BSD licensed compilers died on the vine. Every hardware vendor will want a closed fork for their own architecture which never gets updated properly. This is less evident today when most of the world is only running x86 or ARM, which is licensed rather than manufactured by ARM Holdings, but in the embedded world it will be pretty much obvious.

Re:Thank you, Apple!

[jonwil]

If it was purely about disappointment with the GCC maintainers and their unwillingness to fix issues, accept patches, accept features Apple needs etc etc, it would have made more sense to take the well-developed GCC codebase and fork it. Get others who are also disappointed with the slow-pace of mainline FSF GCC to start supporting the new fork too and eventually the fork will most likely either take over as the de-facto implementation (with everyone shifting to it instead of the FSF GCC ala what happened with X when everyone shifted from XFree86 to x.org) or will get merged back into FSF mainline along with promises to make things better.

But of course its not just about Apple hating the GCC devs. Its also about the fact that if Apple was to continue using/developing/distributing GCC (or a number of other pieces of software such as Samba) then they would have to either fork a really old version (not a viable option) or start shipping versions new enough that they are covered under the GPL version 3. And Apple cant ship GPL3 code because of the very broad patent grant clauses in there (which Apple cant accept because it would potentially let their competitors use such as Google use some of their patents for free)

Re:Thank you, Apple!

[UnknowingFool]

WebKit is based on KHTML. Sure Apple could close source their code further but then they would have to keep updating their branch to match the open fork. That takes a non-insignificant amount of time and effort.

WebKit consists of KHTML code plus Apple's changes and Apple's other code. Prior to 2005, Apple did not release the proprietary parts as they did not have to. Apple did not have to release it as open source but they did anyway. They don't have to match anyone's open fork of their code if they kept it closed.

Over time people will realize why a compiler shouldn't be BSD licensed. There is a reason why other BSD licensed compilers died on the vine. Every hardware vendor will want a closed fork for their own architecture which never gets updated properly.

And who is stopping you from forking a competing compiler based on it? Absolutely no one. The very practical reason that Apple went with Clang/LLVM was that Objective-C development under GCC was becoming stagnant. It was kept under a different branch but under the GCC control. Apple could have forked it, but there were other advantages to using LLVM over GCC like wider multi-threaded support. And have you noticed that many, many parties are developing their own frontends to LLVM?

This is less evident today when most of the world is only running x86 or ARM, which is licensed rather than manufactured by ARM Holdings, but in the embedded world it will be pretty much obvious.

So what you are saying is that it theoretically might be a problem but it isn't today?

Re:Thank you, Apple!

[zakkudo]

Yes. This is exactly why Apple picked up CUPS. There was no possiblity of Apple doing something similar with LLVM/Clang. None at all.

Re:Thank you, Apple!

[PhamNguyen]

I imagine that the issue is not so much that they want to fork LLVM, but they want to integrate LLVM with XCode (I'm guessing they already do, but when I stopped using XCode it was still using GCC) for static analysis. The main difference between LLVM and GCC that allows this is that LLVM is not monolithic, so you can use its code analysis/parsing features without actually compiling, and you can rely on the stability of these components. Licences may or may not be an issue depeding on whether it is necessary to link to LLVM components at compile time or not. But at least with LLVM you have this option (while staying closed source).

Re:Thank you, Apple!

[kthreadd]

True as well, and important too that we don't forget. When we put aside our differences we find that we're all really into it for the same thing.

Re:Thank you, Apple!

[Anonymous Coward]

Apple supports OpenCL compilation using Xcode.

1. Fixed that for you.
2. Tanya Lattner works for Apple. Here is her committing code for the opencl stuff.

Re:Thank you, Apple!

[stenvar]

I don't see what you're complaining about. I've developed software under MIT licenses and got paid for it. Apple or someone pays LLVM developers as well. I don't like the proprietary products Apple is creating with open source software, but the solution to that is just not to buy their products and tell others not to buy their products.

Re:Thank you, Apple!

[Pseudonym Authority]

GCC code based is a fucked-up, convoluted mess and is designed that way, due in no small part to RMS's fear that some evil proprietary coders might steal `his' code away from him. I pity the poor bastard who has to fork it.

Re:Thank you, Apple!

[Anonymous Coward]

LOL!! Generosity? Apple takes an EXISTING project, adds to it for their own benefit and you say that is generous. This is the same company that continued their policy of not making charitable contributions while raking in record profits. So you're a dope,

Re:Thank you, Apple!

[martin-boundary]

I'm not an expert on either of those licenses, but do you really mean that you can't change BSD to AGPL? In that case that's news to me.

You can give out your virginity once only. If you licence under BSD, anyone can take your code and run with it. If you later relicence to GPL, companies can still use the earlier BSD licensed code instead of following the GPL rules.

1) If you license BSD, companies can use the code, and if they sprinkle their own code on top and distribute the software, nobody can take their modified code and freely sprinkle another set of changes on that.

2) If you license GPL, companies can use the code, and if they sprinkle their own code on top and distribute the software, anyone else can freely sprinkle new changes on that.

Re:Thank you, Apple!

[MikeBabcock]

I've yet to see that 'fact' supported by anyone with proper understanding of the issues and no axe to grind.

Re:Thank you, Apple!

[Anonymous Coward]

You're wrong, but here is something else you haven't considered. I have zealots and assholes like you bookmarked. From time to time I'll check to see if you're trolling. Then I'll either mod you down using a separate account or flame you. So, you're not quite as clver as you think you are, detective.

Re:Thank you, Apple!

[cheesybagel]

It is a problem today. NVIDIA, Apple, AMD, Intel are shipping closed source CUDA and OpenCL compilers based on LLVM which basically do the same thing for different architectures. But sure keep dreaming in BSD fantasy land.

Re:Thank you, Apple!

[cheesybagel]

Xcode is an IDE. If you do not know the difference between an IDE and a compiler you need to get yourself educated. Xcode uses clang or gcc to actually compile code AFAIK.

That 'opencl' stuff does not include full support for actually compiling working opencl code in the general sense. Otherwise there wouldn't be people in academia replicating what closed source llvm users such as NVIDIA, AMD, Intel, Apple are distributing out there. Nor would I need to use nvcc to compile my OpenCL code as I do now.

Re:Thank you, Apple!

[cheesybagel]

http://stackoverflow.com/questions/3580222/is-apples-opencl-implementation-using-clang-and-llvm-open-source

So no Apple's OpenCL compiler is not open source.

Re:Thank you, Apple!

[Anonymous Coward]

Strictly speaking, that's not a can't. That is a political motivation for don't/won't.

People do, however, need to think more before they choose a license for their software.

Re:Thank you, Apple!

[UnknowingFool]

So people have released their proprietary compilers. And what is stopping you or anyone from writing their own compilers based on LLVM. Or using the open source ones?

Re:Thank you, Apple!

[kthreadd]

My history is a bit vague here but quickly reading the Wikipedia page suggests that Clang did originate at Apple. The LLVM project as a whole did not however.

Re:Thank you, Apple!

[Anonymous Coward]

You need to educate yourself. Apples opencl compiler isn't Clang.

Re:Thank you, Apple!

[Anonymous Coward]

Why don't you come up with a citation that isn't 3 years old.

Re:Thank you, Apple!

[tlhIngan]

You can give out your virginity once only. If you licence under BSD, anyone can take your code and run with it. If you later relicence to GPL, companies can still use the earlier BSD licensed code instead of following the GPL rules.

And depending on how close new versions stick to the old versions. Eventually the effort of maintaining the old branch is going to get bigger and bigger as the code base diverges.

Anyhow, why does everyone see BSD as bad because it allows closed source development? BSD is bad because it enables copyleft theft as well!

Yes, the GPL allows locking up BSD code as well. A GPL'd project can take code from a BSD project. However, a BSD project cannot take code from a GPL project.

This leads to scenarios that have played out before in the FOSS world - a GPL project takes code from a BSD project. But said BSD project cannot take back the improvements the GPL project made.

In fact, this scenario is even worse than closed source - at least closed source make it don't ask don't tell - the BSD project doesn't care. But the GPL'd project doing the same is flaunting the changed code in their face and they can't do a thing about it. Even worse, the GPL folks are arguing about BSD being locked up by proprietary licenses, when they're just as guilty of doing the same thing - the GPL is locking up BSD code.

Which is fine, if it wasn't for the GPL folks being so in-you-face about it and ignoring the ugly fact that they're just as guilty of the same thing. And claiming superiority about being better than BSD.

Anyhow, I would release my code GPLv2. Make it incompatible with a growing number of GPLv3(+) code out there. Interestingly, GPL can vulture its own as well - a v2 project using some v2+ code can find that v2+ code locked up if the code suddenly incorporates v3(+) code that turns the entire thing GPLv3. The mind boggles.

No wonder I've seen companies start enforcing open-source usage policies - it's much to easy to end up in a conflict where some v2 code and v3 code end up together inadvertently.

Re:Thank you, Apple!

[rtfa-troll]

Which interests?

I am talking about several fundamental interests you have in your code

• as a user, in return for having handed out your code you would like to be able to use other people's code
• as a developer you would like your code to grow and become more valuable so it can be used for more
• the right to get paid for proprietary use of your code.

If someone wants to make a proprietary version from your code, you can then discuss with them. They can pay you if they think it's worth it. If you put it under the AGPLv3 this is pretty easy and clear. If you put it under the BSD license then they just take and that's it.

Re:Thank you, Apple!

[kthreadd]

I guess it's a matter of personal optinion. Persionally I don't mind that someone can use open source code that I wrote and use it in a proprietary version. I don't see that as a problem. If they would pay me I would much prefer that they pay me for writing the source code or modify it for their needs, rhather than maintaining some dual licensing thing.

Re:Thank you, Apple!

[Anonymous Coward]

An old GCC version was ported over to plan9. It was done by a single person and was a full time job so it's definitely not the "fucked-up, convoluted mess" you make it to be.

Re:Thank you, Apple!

[Anonymous Coward]

*was not* a full time job...

sorry

Re:Thank you, Apple!

[rtfa-troll]

I guess it's a matter of personal optinion.

Choice of license can certainly be a matter of personal judgement, and sometimes even more complex than that. There are small amounts of code, for example compression code and media codecs, where it's a big benefit for the code to be used everywhere, even in your competitors software, so that different applications are compatible. Please note, I didn't say "never use the MIT license". I said "change to MIT where you see a real benefit".

Personally I don't mind that someone can use open source code that I wrote and use it in a proprietary version. I don't see that as a problem. If they would pay me I would much prefer that they pay me for writing the source code or modify it for their needs, rather than maintaining some dual licensing thing.

I would say that, in most (though not all) cases, the AGPLv3 actually encourages this model. You add little improvements for each customer; the customers tend to be happy to share back because they know their competitors can't take the code and use it against them without also making it available back to them when they distribute. Your code gradually improves and becomes more useful. More people use it and so more people see special needs where they would like something developed for them.

It's very important to remember that the GPL licenses are designed with the interests of users in mind. The BSD licenses are designed with the interests of other developers in mind. You, yourself, have full right on your own code no matter what license you have put it out in already. This normally means that your own interests are more closely aligned with your users ("customers") than with other developers ("competitors"). The exception comes when other developers are working together on a project with you and contributing back in which case they become "partners". In most cases AGPLv3 is the best way to encourage that.

Re:Thank you, Apple!

[Anonymous Coward]

An absurd defense of the GCC project; remember, the politics surrounding it caused it to fork once already (creating EGCS), and the fork was so well-maintained it ended up as the main GCC line. And suddenly everyone conveniently forgets about EGCS and GCC can go back to pretending there is no problem with it.

It seems some OSS do not like the freedom to create competing OSS projects...

Re:Thank you, Apple!

[Anonymous Coward]

>RMS
>afraid of stolen GCC code
Cool story bro, tell us another

Re:Thank you, Apple!

[ilguido]

Um what? Clang is open source. WebKit was open sourced by Apple. Under the GPL they are only obligated to release modifications to the original KHTML base code. They are under no obiligations to release JavascriptCore or WebCore but they did.

They actually are: JavascriptCore and WebCore are both under the LGPL and KHTML derived.

Re:Thank you, Apple!

[ilguido]

So, to put it straight:
GPL "steals" code from BSD = your wife cheats on you and you feel ashamed because you know it and there's little you can do about it.
Close source "steals" code from BSD = your wife cheats on you and everybody knows and laughs at you, but you don't know so you're happy.

For some reason BSD zealots prefer the latter situation and don't know why everybody laughs at them.

Re:Thank you, Apple!

[kthreadd]

I think that the GPL is a good document for describing how an optimal world would look like. A really nice one actually. But the problem is that it's going too far. A lot of businesses basically have a policy about not allowing any GPLv3 through the door. Which is very sad. And that's also why I generally recommend that you use a permissive license from the start and only move to something more restrictive if you find it necessary. It's possible to change from GPL at a later stage, but it's cumbersome if you have received any form of contribution because everyone have to agree on it. Going the other way is much easier, you basically just change it. A competitor might of course create a closed source fork based on your earlier work. Yes, absolutely. And it's usually less of a problem. Open is a feature. And if your project is so successful that someone does make a closed fork from it then you're already ahead of most others.

Re:Thank you, Apple!

[Anonymous Coward]

Dumbest nonsense I've read in a long time.

Re:Thank you, Apple!

[Anonymous Coward]

If it was purely about disappointment with the GCC maintainers and their unwillingness to fix issues, accept patches, accept features Apple needs etc etc, it would have made more sense to take the well-developed GCC codebase and fork it

It's clear you've:
* Never worked on a large C project.
* Don't know the history of GCC(the current incarnation is a rewrite).

Re:Thank you, Apple!

[Sigg3.net]

A witch!!?!

Re:Thank you, Apple!

[Anonymous Coward]

I reject your hypothesis on the basis that microsoft is evil and when things unrelated to or in competition with microsoft are criticized it must be microsoft paying people to have that opinion because they worry about the influence that the comments in slashdot stories have on their current and potential customers. rtfa-troll is clearly a threat to microsoft and must be responded to in a critical way!

Re:Thank you, Apple!

[Anonymous Coward]

nvidia use LLVM and the changes to LLVM that they make they contribute back to the project, the fact that they also use a closed source tool in their compile chain is completely irrelevant to the LLVM project and it would make no difference whether they use a compiler infrastructure under a proprietary, permissive OSS or even restrictive OSS license.

Re:Thank you, Apple!

[Anonymous Coward]

BSD is bad because it enables copyleft theft as well!

It's not theft and you know it, comments like that are made to deliberately undermine the credibility of the open source community.

Re:Thank you, Apple!

[angel'o'sphere]

Your point is exagerated or even wrong.
Apples Guis on top of GCC and the LLCM suit still leave the "original" GCC and LLCM as ordinary full GPLed command line tools available. I see no fact that they exploiting/cheating with the GPL somehow.

Re:Thank you, Apple!

[cheesybagel]

I might actually do it. But I would fork LLVM under the LGPL.

Testing?

[Anonymous Coward]

So I guess only testing remains. Hopefully major bugs would be sorted out in an year or two.

Linux

[Anonymous Coward]

Apparently, Torvalds is evaluating following BSD suit and start using clang for the kernel. The remaining issue two months ago was GCC extensions, which seems to be sorted out.

Amazing times if GCC is thrown out.

Re:Linux

[_merlin]

Well it's not surprising as the GCC maintainers are becoming completely impossible to work with. Each new version of GCC becomes less compatible with 3rd-party linkers and less popular runtime libraries (e.g. Solaris). It also becomes harder to build a working compiler for anything other than Linux. Often you need to hack stuff up to get it to build at all on SPARC, and even then it won't necessarily produce working executables. Red Hat GCC usually has fewer issues than FSF GCC, but by the time Red Hat fixes make it upstream, even more bugs will have been introduced. I think it comes down to lack of competition. GCC just became too popular for its own good, and that inflated the egos of the maintainers to the point where they don't give a shit about users. CLANG is still in the state where it's fighting for market share, so they have to care about users to get any traction, but if it becomes popular enough, it will probably go the same way as GCC.

Going slightly off-topic, Apple (principal CLANG contributor) is a lot like GCC. Back when they had almost no market share, they actually cared about users and did awesome shit. But now they have some traction they're a bunch of cunts. Tiger was a questionable update, and every OSX update since has been a load of shit. Mountain Lion makes the UI really annoying, and OSX Server is now completely useless. Final Cut Pro X is a steaming turd when the old Final Cut Pro was best in class software. Old iMovie wasn't great but it was usable. New iMovie has destructive editing, no proper timeline, and is completely useless for any half serious work. And they've made it so you can't run old iMovie or Final Cut on new versions of OSX, and you can't run old OSX on new machines. I'm waiting for them to do the same thing to Logic.

Even Microsoft kind of cared about users back when they were the underdog. They developed customised BASIC implementations for all the microcomputer manufacturers, DOS was for the most part better than CP/M '86, and Office for Mac kickstarted the platform. Everyone knows where market domination led them.

TLDR: market domination is the worst thing that can happen to anyone.

Re:Linux

[TheRealMindChild]

It also becomes harder to build a working compiler for anything other than Linux

Now, it is even less possible. I like to bring up DOS as an example that can't even fit the paradigm of the C++11 specification. How on earth are you going to have threads in DOS? You also have the long long int type, where if you need to use that on a 32bit system, it will need emulated

Re: Linux

[Celarent Darii]

The phenomenon is not just restricted to IT companies. It's the borken part of human nature. Te Greeks calledit 'hubris'.

Re:Linux

[Moridineas]

I don't disagree at all with the main thrust of your post, but in nitpicking pedantic mode, I do disagree about versions of OSX.

Tiger was a questionable update, and every OSX update since has been a load of shit. Mountain Lion makes the UI really annoying, and OSX Server is now completely useless.

Tiger -- OSX 10.4 -- was released in 2005 and was a great update. Two of the biggest features were Spotlight (an every day usage feature) and I believe the Dashboard.

Leopard -- 10.5 -- was another good release. In addition to full x86 support, Leopard added Time Machine, Spaces (virtual desktops), Boot Camp, etc.

Snow Leopard -- 10.6 -- 2009. my favorite release. SL was largely a refinement release with a new rewritten Finder and general speed increases. I still run 10.6 ln my laptop and many users (myself included) would argue it was the best OSX release.

Lion -- 10.7 -- no idea what is supposed to be new or good in Lion. Resize windows from any border is the only thing I can think of. I use it at work on an old macpro and hate it compared to SL.

Mountain Lion -- 10.8 -- Again, really not sure what improvements there are supposed to be. I would say a better release than LIon, with some real interface improvements (to expose/mission control) but still crap compared to SL.

So in short, I don't think it is at all fair to say that all releases since Tiger have been crap. Maybe you meant Lion, in which case I 100% agree!

Re:Linux

[Anonymous Coward]

market domination is the worst thing that can happen to anyone.

This. It contains the seeds of its own destruction.

But technical leaders employed by companies usually work for somebody, and if they piss off too many of their users and coworkers, guys like Scott Forstall, Steve Sinofsky, and (perhaps) Andy Rubin can pushed aside. In the open source world they're likely to stick around for a decade or more... if you want changes you'll have to start your own fork.

Re:Linux

[DarkOx]

How on earth are you going to have threads in DOS?

The same way you always have the same way its done on every embed platform. A private to your application threading model. There is nothing to stop you from implementing any kind of scheduling your want on top of DOS as it does not do any, and nothing that will stop you from doing whatever you like with interrupts, software or otherwise.

You also have the long long int type, where if you need to use that on a 32bit system, it will need emulated

yes. Just like what used to be done for floats and 32-bit values on x86 DOS platforms.

Re:Linux

[gerddie]

It also becomes harder to build a working compiler for anything other than Linux

Now, it is even less possible. I like to bring up DOS as an example that can't even fit the paradigm of the C++11 specification. How on earth are you going to have threads in DOS?

This can be done with user space threads

You also have the long long int type, where if you need to use that on a 32bit system, it will need emulated

long long int existed as for quite some time, gcc and msvc support in on 32 bit platforms.

Re:Linux

[interval1066]

IF YOU NEED threads in DOS you can have them, although the only legitimate use for DOS I can think of is to support legacy libraries and old architectures. I have ONE example; I worked for a company that had to use libraries built with Borland C (and not CodeWarrior, I'm talking old-school Borland C, 4.5 I think was the release)), the libraries were required to access a proprietary hardware bus, and the licensing company wasn't updating. But other than scenarios like that, I don't see a good reason for using DOS. If you think you need DOS as a platform for your wizbang neato device, you need to re-think your idea. Even that company was getting ready to release 32 bit shared-libs (yes, moving to a unix-ish architecture) for access to their stupid bus by the time I left. Even if your device idea for some reason requires using a 16 bit processor there are better embedded solutions that you can use now than DOS.

Re:Linux

[_merlin]

Tiger -- OSX 10.4 -- was released in 2005 and was a great update. Two of the biggest features were Spotlight (an every day usage feature) and I believe the Dashboard.

Switch from SystemStarter to launchd was definitely a massive improvement, and there were improvements in other areas but it isn't all rosy. Tiger introduced bugs in Finder copy code which could result in not all files being copied when you copied multiple files between disks, and no notification that the copy hadn't completed successfully. To make it worse, moving multiple files between disks could result in not all selected files being copied to the destination, but all files being deleted from the source. This was fixed in 10.4.2 IIRC but it should never have made it to a production release. Tiger also changed the disk image framework to always report images using layout NONE as having invalid checksums. Apple Mail in Tiger replaced standard MBOX message storage with proprietary ELMX format, and MBOX export was broken so message boundaries didn't work for certain message content. Storage formats for Address Book and iCal were also fucked with in unpleasant ways.

Leopard -- 10.5 -- was another good release. In addition to full x86 support, Leopard added Time Machine, Spaces (virtual desktops), Boot Camp, etc.

Boot Camp was in Tiger for x86, but anyway... Removed support for input managers, removed write support for HFS, introduced garbage-collected Objective-C which has already been deprecated, removed support for Level 1 Postscript printers, removed support for AFP over AT.

Snow Leopard -- 10.6 -- 2009. my favorite release. SL was largely a refinement release with a new rewritten Finder and general speed increases. I still run 10.6 ln my laptop and many users (myself included) would argue it was the best OSX release.

Broke many Cocoa Java applications, OSX Server became far less stable. Removed NetInfo with no real unified configuration store to replace it and there are now XML configs all over the place. I still use it because it's the last release that supports old Final Cut Pro.

Lion -- 10.7 -- no idea what is supposed to be new or good in Lion. Resize windows from any border is the only thing I can think of. I use it at work on an old macpro and hate it compared to SL.

This is the release where OSX Server became completely useless. No more print quotas, adding Windows machines to a domain on OSX Server is useless, no QTSS, fucked up dumbed down admin UIs.

Re:Linux

[unixisc]

Can Torvalds also evaluate using a non-GNU userland, and instead use something like BusyBox and other Unix like utilities, either from BSD or SVR? Something not tied down by GPL3 and whatever RMS decides is the new sin in the church of St iGNUcius? Stuff that is either GPL2 or earlier, or BSD, CDDL, X11, or some such OSS license? So that people can stop whining about the OS being GNU/Linux, and instead become something else?

Re:Linux

[BitZtream]

32 bit shared-libs (yes, moving to a unix-ish architecture)

What part of shared libs is related to UNIX other than 'yes, it supports it'. What OS doesn't support shared libs? Since it doesn't have to be a function of the OS any more than threading does, I don't see how such a statement is relevant. DOS supports DLLs too you know.

Re:Linux

[kthreadd]

Torvalds only cares about the kernel, and some diving app. A distribution can chose any userland it wants.

Re:Linux

[Anonymous Coward]

What the hell does Torvalds has to do with userland and what the hell does Clang C++11 support has to do with Linux kernel? I don't think it's written in C++.

You could replace userland with whatever you want since day 0 (see all the embedded Linux distros), so you can go and roll your own BSDebian, with blackjack and hookers.

Re:Linux

[Anonymous Coward]

At least in GCC's defense, the success of apps, platforms, etc mmade the dickishness a two-way dance. It is just as easy to argue that gcc's maintainers reacted to arrogance and dickishness from them wanting gcc to make them its exclusive bff, give them proverbial handjobs, etc to keep them working throwing bones to gcc. In the case of Sun/ Solaris, let us not forget the inherent alpha dickhead behavior that comes from Oracle. MS and Apple have their own proprietary/competing products to use to increase their developers' devotion to the platform, rather than their freedom.

Re:Linux

[Kjella]

Well it's not surprising as the GCC maintainers are becoming completely impossible to work with. Each new version of GCC becomes less compatible with 3rd-party linkers and less popular runtime libraries (e.g. Solaris). It also becomes harder to build a working compiler for anything other than Linux. Often you need to hack stuff up to get it to build at all on SPARC, and even then it won't necessarily produce working executables. Red Hat GCC usually has fewer issues than FSF GCC, but by the time Red Hat fixes make it upstream, even more bugs will have been introduced. I think it comes down to lack of competition.

Or maybe it's just another sign of Sparc/Solaris' slide into... well, not irrelevancy but a hardware/software niche that neither developers or maintainers actually have. OpenSolaris is gone, Oracle is probably not doing much if anything to support GCC so how much of it is added hubris and how much of it is increasing obscurity? I just tried a search for SPARC on eBay and ignoring parts there's maybe 150 servers for sale. That's somewhat more than Commodore 64 and Amiga 500, but it's still rare/vintage. Yes, I know it's not dead yet and some huge enterprises use it but 99.9% of people have never seen one and never will.

Re:Linux

[johnkzin]

If only there was a company whose job was to make gcc/gdb ports to every platform on earth, with contracted deals with the platform makers (Intel, Sun, Sega, Sony, Hitachi, etc.) ... such that gcc provided C, C++, and even some Objective-C support, uniformly across platforms, with as much platform specific optimization as possible.

Oh... wait. There was such a company. Until Redhat bought them and killed them. (Cygnus Support / Cygnus Solutions, purchased by Redhat in very late 1999/ early 2000 because RH was afraid Cygnus would go into the business of having their own Linux distro and compete with RH...)

Re:Linux

[jonwil]

Speaking as someone who actually attempted to hack on GCC in the past (and who actually has a copyright assignment on file with the FSF) I concur with your statements about how crap GCC development has become. I wanted to add Windows thread-local-storage support to GCC (the OS-level logic behind the Visual C++ __declspec(thread) keyword) and even understanding the mess that is the GCC codebase was annoying, let alone trying to find out the right way to get the code to output the necessary assembler into the assembler file (the one that is then compiled with gas). Never did get the feature working and never could get anyone in the GCC development community to point me in the right direction either.

Re:Linux

[cheesybagel]

CodeSourcery would be another such company until it was bought by Mentor Graphics.

Re:Linux

[Billly Gates]

Dos is EOL and obsolete. Get over it.

Yes Freedos is available and some companies still use it. My point is it should not be used for new software nor software development as it is a dead platform in a different era just like XP should be avoided by this time next year.

DOS really is not an OS anyway and it can't even handle I/O. It uses the bios for keyboard import because it is so so braindead crippled. What a piece of garbage. My ant MS zealotry started from DOS way before I knew what Linux was.

Re:Linux

[Jeremi]

Tiger was a questionable update, and every OSX update since has been a load of shit.

Point of order: Snow Leopard was actually pretty good. It may be the best OS/X of all of them, in fact.

Re:Linux

[tyrione]

Keep talking out your ass with setting up a statement solely to bad mouth Apple products. One big rambling pile of shit rant that is easily refuted.

Re:Linux

[Anonymous Coward]

What's wrong with using the pthread thread-specific data API (pthread_setspecific, etc)? I've used it in multiple projects, including one where I had to support both Windows and Unix/Linux (I used C++ wrapper classes to hide the platform differences).

Re:Linux

[maccodemonkey]

Final Cut Pro X is a steaming turd when the old Final Cut Pro was best in class software.

Honestly, I know a lot of video editors (I'm not one of them) who would not consider Final Cut Pro best in class. They complained about it constantly. Strangely enough, those are the same people who complained about FCPX.

Most of the people who are complaining FCPX switched to Premiere a years ago, and complain constantly even though they're not using FCPX. It's mostly to continue justifying their transition to Premiere when FCS got long in the tooth. "Well of course I made the right choice in switching to Adobe! FCPX is crap!"

That's not to say FCPX doesn't have downgrades. But they are the sort of downgrades that probably aren't all that important (like no tape workflow, who still REALLY needs a tape workflow out there built into the editor?), but are the sort of features that people say they might possibly use someday for nitpicking purposes.

Again, not that FCPX doesn't have it's issues, but a lot of the stuff these days is wildly overblown, and usually from the same corners that didn't like FCPS either.

Re:Linux

[spitzak]

I use "__thread" in gcc. Did that not work for you?

Re:Linux

[Anonymous Coward]

DOS really is not an OS anyway and it can't even handle I/O. It uses the bios for keyboard import because it is so so braindead crippled.

If you had ever programmed in assembly on DOS you would know this is false.

Re:Linux

[Moridineas]

It seems you're really arguing that some of the releases had some deprecations that you didn't like (nothing you listed affected our company at all--I applauded deprecation of AppleTalk!) and some that effected a relatively small number of users (I'd never heard of anything you mentioned). Every Apple point release I've ever used has had some bugs--hardly unique to post-Tiger.

I would argue that OSX 10.0, 10.1, and 10.2 were effectively betas that lacked critical features and were not usable in production environments. 10.3 is the first version I felt comfortable rolling out to our users in even a trial basis. By your standards, 10.3 was the pinnacle of OSX?

I disagree!

Re:Linux

[Moridineas]

I do, incidentally, feel that 10.4 was the pinnacle of OSX GUI. We still have one PPC 10.4 (dual 1.25ghz G4--tells you how old the machine is!) running 24/7 for a server app that has some PPC-only extensions -- so no rosetta. I VNCed in the other day and it has such a pleasant appearance compared to flat monochrome grey crap in post-Lion OSX.

Re:Linux

[jonwil]

At the time the specific Windows OS-level functionality related to thread local storage wasn't supported by GCC so __thread (if it existed at the time, I forget if it id) didn't work the way it should.

Re:Linux

[interval1066]

Ok conformity cop. Shared libs in dos can be made, but statically linked are more common. That's what I meant. Now go play.

Re:Linux

[O'Nazareth]

The standard library has the right to throw an exception if threading is not available and you try to create a thread. It actually happens like that on Linux if you forget to link to pthread. For the concurrent memory model it is just hardware specific.

Re:Linux

[odysseus_complex]

A thread-local variable resolves to a single instruction on x86 and 3 instructions each on ARM and PPC. Using the pthread thread-specific API requires a function call (at the minimum, potentially an OS call at worst case) and all save/restore instructions that this implies. In an application that is vulnerable to performance issues and one has to make multiple references to function-global, thread-specific variables then using pthread thread-specific data is murder on timing characteristics. Your general Windows/Linux/MacOS application may not need this level of performance but an embedded, real-time app requires this level of detail.

Re:Linux

[Anonymous Coward]

FCPX was completely horrid when it came out, but it got progressively better. It's the best software on the market right now, in my opinion.

I just wish they'd make a version of compressor for Linux so I can build a render farm.

except for garbage collection

[Anonymous Coward]

I noticed that "minimal support for garbage collection" had a conspicuous "no" (support) on gcc's C++11 feature list.

At the risk of sounding like Bill Gates ("640K should be..."), I don't see why C++ needs language-based or standardized garbage collection support. That's a huge can of worms for both compiler vendors and app developers. If you want that, you probably want a higher level language for your application anyway.

Re:except for garbage collection

[TheRealMindChild]

C++ is now split into two factions; low-level C++ where you use it like C with classes, and high-level C++, where the language is treated like compiled javascript. Unfortunately (from my perspective), a majority of C++ programmers choose the latter approach.

Re:except for garbage collection

[TheRaven64]

I don't see why C++ needs language-based or standardized garbage collection support

The C++ standard doesn't specify GC, it merely relaxes the constraints on when destructors are called and when memory is reclaimed in such a way that an implementation using garbage collection is now possible. This is more a standard library issue than a compiler one, although in theory a compiler might use GC-managed storage for objects with automatic storage. This support basically means that if you take C++ code and link it against the operator new() implementation provided by the Boehm GC it remains a standards-compliant implementation.

Re:except for garbage collection

[rtfa-troll]

"Interesting", said a person who hasn't followed C++ so much recently. Does anyone know how easy is it to mix different garbage collection policies in different threads in the same application? Looking at the FAQ it seems this would be pretty nasty? Is it easy to have a real time thread that uses only manual allocate/free and another which might get blocked during garbage collection?

Re:except for garbage collection

[VortexCortex]

I don't see why C++ needs language-based or standardized garbage collection support.

Well, I wrote my own Hash Map implementation. Before that I had my own Linked Lists too. Before C++ came along I even maintained my own OOP implementation in C with a spiffy pre-processor to convert syntactic sugar into the equivalent ugly object oriented C code riddled with namespace prefixes, indecipherable pointer math for dynamic (virtual) functions (actions), and statically complied variable (property) look-up tables for run-time type inspection (reflection).

It led to incompatibilities between codebases -- My Entities+C wouldn't be compatible with your C+OOP. Hell, we didn't even use the same terminology, or necessarily even support the same feature sets. The point is, I wasn't the only one who was doing that (see also: Objective C). There were lots of us, it was a huge waste of duplicated effort. So many, in fact, that C++ was born, and the STL too, And now C++11 has Hash Maps, I don't need to maintain my own going forward (use unordered_map). This means I don't have to worry if the hashmap implementation I used is compatible with another library's or if it'll run on another compiler or what its performance guarantees are. I can just use the language implementation -- which while not always optimal, is usually good enough -- and if I need to I can implement my own version tailored for my specific use case.

So The same reasoning is used for including a garbage collector / local memory pool management. Calling into the kernel code every allocation / deallocation of dynamic memory is slow. Yeah, you can override the new operator and/or create your own replacement allocator, but here's the thing: You can add OOP to C, and build your own collection APIs too. That's lame boorish work, not really beneficial to create that if we can avoid doing so, since the program itself typically isn't enmeshed deeply with the memory management details. We're better off if GC is already done, standardized, tailored to work well within the system we're compiling on, and completely optional for folks like you who would rather jump a codebase to a whole new language rather than add a GC...

Maybe once you've written a few GCs in C++ more times than you care to count then you'll have a different perspective -- Oh, but wait, we don't need your perspective, it's in the standard. The feature we all decided we should have will be supported.

I think you're underestimating the kinds of applications where we could use such features, or the actual need / demand of the feature itself, and even the "level" of the language as you define it I find suspect. I mean, C++ is right up there with the highest of the high level languages, bucko. EA (the game company) created their own STL replacement basically just to add a GC and hashmaps, because they were tired of reimplementing these features IN EVERY DAMN GAME. Now, games aren't the only applications being made, but you get the point. EA didn't employ the only set of programmers doing this -- Take me for example.

That is to say, I write bytecode interpretors & VMs for my compilable embeddable languages that are little more than macro assemblers during their 1st iterations. That's low level coding, sometimes even translatable into machine code (depending on the language) and even a few of the ASM-like languages I've made have garbage collection built in. That is to say: GC is not a bullet point that exclusive to any "level" of programming language. I'd consider it a BASIC feature.

Re:except for garbage collection

[TheRaven64]

It's likely to be very difficult, depending on how the GC is implemented. It would be easy to mix if you don't share objects between thread, but then you may as well use different processes. Mixing different GC policies in a single application is usually quite difficult, but it's possible if your primitive operation is reference counting and you create a full GC by adding concurrent cycle detection. You can then control at different granularities when the cycle detector is run. This gives you realtime allocation and deallocation for acyclic objects in the realtime thread (assuming that your allocator is deterministic), and allows you to explicitly schedule the cycle detector runs.

My understanding was that the GC stuff was added at the request of Microsoft, so that the C++ dialect that they use in .NET can become closer to the standard. The idea is more that you'd have a single C++ codebase that would either run in a .NET VM, or compiled to native code, depending on your deployment target.

Re:except for garbage collection

[sydneyfong]

The most unfortunate thing with the latter case is that when you really attempt to treat it like compiled Javascript, the gotchas with C++ is long enough to fill a thick book (literally).

Re:except for garbage collection

[SpinyNorman]

I don't have a problem with the standard allowing for garbage collection, but I'm curious what types of real-world use cases make GC for C++ more convenient that explicit storage management?

The combination of STL and destructors-free-memory (on the frew occasions you need non-STL datastructures) seems convenient enough to me.

Re:except for garbage collection

[paavo512]

C++ is now split into two factions; low-level C++ where you use it like C with classes, and high-level C++, where the language is treated like compiled javascript.

What you mean by "split"? The main advantage of C++ is that it provides so many levels and paradigmas that one can smoothly shift the code around at a large scale, either in space or time. This also allows for real refactoring of the code and introducing new conceptual levels "inside" the language.

Re:except for garbage collection

[Anonymous Coward]

You didn't mention the actually good way to use C++. Expose elegant and easy to use interfaces that hide all the tricky optimizations that were required for performance. The business logic or your library clients never see a pointer. At the same time you are unconstrained about what you can do when you need to. The only way you can do that in most languages is to write the optimized code in one language, like C or assembler, and the high level code in some other language. Huge problem there is the overhead of cross-language dispatch (at minimum, no inlining) which means that the operations you expose have to be coarse grain and you have to somehow deal with accessing foreign memory layouts or you have to copy data. C++ simply doesn't have these problems. Templates is a huge feature designed in part for safety, but more-so to allow an extremely fine grained interface to your optimized code with no performance penalty. Migration of code is also no problem since your optimized and inefficient code are in the same language. You may have just been only exposed to poor C++ programmers, but more likely I think you simply do not have a full appreciation for what can be done in C++.

Re:except for garbage collection

[paavo512]

Calling into the kernel code every allocation / deallocation of dynamic memory is slow.

Yes it is, and no sane memory allocator is doing that, they all allocate memory from the OS in large chunks and then distribute it in-process as fast as they can. You are attacking a strawman. Anyway, this has nothing to do with GC, GC needs to allocate and deallocate memory as well.

Re:except for garbage collection

[Anonymous Coward]

So? With OOP, template metaprogramming, and lambdas (functional programming feature) C++ is the most powerful language ever designed by people. Why is it surprising that you need to learn quite a few gotchas to master this powerful tool?

Re:except for garbage collection

[Anonymous Coward]

RAII works fine when you have a strict ownership hierarchy, where a parent owns its children and nothing stores a reference to something which it doesn't own.
GC is the only practical solution when you have unrestricted graphs. Examples include high-level interpreted languages such as Python or Lisp, or complex simulations.

Re:except for garbage collection

[Anonymous Coward]

What you mean by "split"? The main advantage of C++ is that it provides so many levels and paradigmas that one can smoothly shift the code around at a large scale, either in space or time. This also allows for real refactoring of the code and introducing new conceptual levels "inside" the language.

"Jack of all trades, master of none." Applies more and more to C++ with every update to the standard, IMO.

Re:except for garbage collection

[SpinyNorman]

OK - Thanks.

I guess reference counting would work in those situations too.

An alternative to GC would be an STL replacement with reference count-based destruction.

Re:except for garbage collection

[spitzak]

malloc does not call into the kernel.

Re:except for garbage collection

[Anonymous Coward]

It just occurred to me that one use case would be a complex framework written in C++ that could be extended by custom code. Now let's say the framework was a long lived process (uptime in days or weeks), so that memory leaks need to be caught. The framework developers might be confident in their ability to catch their own, but maybe not have so much faith in their customers' code.

Re:except for garbage collection

[TheRealMindChild]

The business logic or your library clients never see a pointer.

So I see you are in the latter group. You are the reason we can't have nice toys

Re:except for garbage collection

[smellotron]

Calling into the kernel code every allocation / deallocation of dynamic memory is slow.

If you haven't already, I encourage you to download the glib source code and trawl around. Pick the latest code, or whatever you interact with on a daily basis. Check out the malloc code, it's not as daunting as it sounds. You should discover a few things:

• If your malloc size is big enough to trigger a mmap (128KB IIRC), then you are absolutely correct that the runtime library will invoke the OS on every allocation/deallocation. Until you hit your number-of-maps limit, at least. So yeah, repeated allocation and deallocation of large blocks of memory is bad in this implementation. But don't throw out the baby with the bathwater! mallopt can be used to tune the allocator to your program's expected behavior. As in: short-lived block sizes should probably be below the mmap threshold.
• If you don't trigger the mmap size threshold, then the allocator only goes to the OS if it needs to increase the size of the heap. Again, this behavior is tunable: how much to pull from the OS at once, and how much overhead to allow before returning space back to the OS.

If you're not writing software with high performance requirements, you can probably ignore all of this, because your program's bottlenecks are probably somewhere silly (and nobody cares, anyhow). If you are, this level of control is probably desirable whether you're using GC or deterministic deallocation.

Re:except for garbage collection

[smellotron]

My copy of malloc calls sbrk and mmap/mremap/munmap—all kernel functions. How does yours get more virtual address space?

Re:except for garbage collection

[UnknownSoldier]

> EA (the game company) created their own STL replacement basically just to add a GC and hashmaps, because they were tired of reimplementing these features IN EVERY DAMN GAME

No the _real_ reason was because STL was horribly designed and implemented in places:

However, some aspects of it make it hard to use and other aspects prevent it from performing as well as it could. Among game developers the most fundamental weakness is the std allocator design, and it is this weakness that was the largest contributing factor to the creation of EASTL. Secondarily was the lack of std STL containers designed to be memory-friendly. There are additional reasons that will be discussed below.

:

The following is a listing of some of the reasons why std STL and its current implementations are not currently ideal for game development. There are additional reasons, but the list here should hopefully convey to you some sense of the situation. Each of the items listed below deserves a document of its own, as a single sentence alone cannot fully convey the nature or significance of these items. Some of the items refer to the STL design, whereas some of the items refer to existing STL implementations. It would be best if these were discussed independently, but to many users this distinction is often of little practical significance because they have little choice but to use the standard library that comes with their compiler.

* std STL allocators are painful to work with and lead to code bloat and sub-optimal performance. This topic is addressed separately within this document.
* Useful STL extensions (e.g. slist, hash_map, shared_ptr) found in some std STL implementations are not portable because they don't exist in other versions of STL or are inconsistent between STL versions (though they are present in the current C++09 draft).
* The STL lacks functionality that game programmers find useful (e.g. intrusive containers) and which could be best optimized in a portable STL environment. See Appendix item 16.
* Existing std STL implementations use deep function calls. This results in low performance with compilers that are weak at inlining, as is the currently prevalent open-source C++ compiler. See Appendix item 15 and Appendix item 10.
* Existing STL implementations are hard to debug. For example, you typically cannot browse the contents of a std::list container with a debugger due to std::list's usage of void pointers. On the other hand, EASTL allows you to view lists without incurring a performance or memory cost. See Appendix item 2.
* The STL doesn't explicitly support alignment requirements of contained objects, yet non-default alignment requirements are common in game development. A std STL allocator has no way of knowing the alignment requirements of the objects it is being asked to allocate, aside from compiler extensions. Granted, this is part of the larger problem of the C++ language providing minimal support for alignment requirements. Alignment support is proposed for C++09.
* STL containers won't let you insert an entry into a container without supplying an entry to copy from. This can be inefficient in the case of elements that are expensive to construct.
* The STL implementations that are provided by compiler vendors for the most popular PC and console (box connected to TV) gaming platforms have performance problems. EASTL generally outperforms all existing STL implementations; it does so partly due to algorithmic improvements but mostly due to practical improvements that take into account compiler and hardware behavior. See Appendix item 20.
* Existing STL implementations are hard to debug/trace, as some STL implementations use cryptic variable names and unusual data structures and have no code documentation. See Appendix item 2.
* STL containers have private implementations that don't allow you to work with their data structures in a portable way, yet sometimes this is an important thing to be able to do (e.g. node pools). See A

Re:except for garbage collection

[TheRaven64]

The main use is C++ code coexisting in an environment with other high-level languages. By relaxing this constraint, they make it possible to compile C++ to Java or .NET bytecode (handling multiple inheritance is painful, but possible) and have it run in a completely GC'd world. Having conservative GC in C++ isn't that useful, but being able to take a large legacy C++ codebase, recompile it, and run it in today's environment of choice (whatever that happens to be) is.

Re:except for garbage collection

[gbjbaanb]

GC also has to pause your program (even for a short time) and then copy memory blocks around to compact the heap (or it will rapidly run out). Memory copying is a slow operation, and the additional time spent calculating which blocks to move is also adding extra time that non-GC systems don't incur.

Then there's the GC killer - locality of data, in most non-GC apps memory is allocated contiguously so it can be read from relatively slow RAM into CPU cache in a straight hit, in GC systems the memory blocks can more often be located all over the heap, and each one is referenced via an intermediate GC pointer, which means you need many hits to read the same data - with today's super-fast CPUs requiring data to be present in the caches, this can murder performance on a GC system.

Saying GC is a basic feature just means the OP has bought into the hype without giving it much critical review.

Re:except for garbage collection

[spitzak]

It does not call the kernel on every malloc call, that's what I meant. The op acted as though malloc/new called the kernel every time.

Re:except for garbage collection

[Anonymous Coward]

...then how does it acquire more memory for the program?

Re:except for garbage collection

[spitzak]

The op said "Calling into the kernel code every allocation / deallocation of dynamic memory is slow." I'm pretty certain no malloc has done that for decades.

Re:except for garbage collection

[smellotron]

that's what I meant

Yeah, I was hoping that. Sorry, you didn't really deserve a snarky reply, I was just titillated at the idea of a pure-userspace malloc under a multi-tasking OS. But seriously, see my other comment about glibc code. If a program does malloc/free above the size threshold for mmap, then every call does get passed on to the OS. Additionally, if your allocated footprint grows and shrinks by large amounts in LIFO order, you may see excessive sbrk calls. All of this is tunable by mallopt.

BSD

[BasilBrush]

One of the great things about Clang and LLVM are they are BSD licensed rather than GPL.

Re:BSD

[Microlith]

So are you seriously trying to start this flamewar again? Do you have nothing else to say?

Re:BSD

[stinerman]

Indeed. I'm a bigger fan of the GPL in most cases, but there is room enough in the world for both camps (crazy talk, I know). Now you have your compiler under a suitable license for you and your fellow travelers.

Re:BSD

[Dr_Barnowl]

GPL is probably a better license for a compiler, if only because it prevents the stupid proliferation of proprietary extensions that have plagued the compiler market.

Re:BSD

[Anonymous Coward]

The only plague on the compiler world are GCC extensions.

Re:BSD

[thatkid_2002]

I can't see the harm in a compiler being GPLed. In fact, GPLing a compiler makes sense because it is a tool where users rights (distributing freely, mainly) are important and where contributing back optimisations is useful and important.
What exactly is the advantage of a BSD license for a compiler?

Re:BSD

[Anonymous Coward]

There is no "flamewar" to start. Some GPL advocates may feel the need to argue, but that won't change the facts.

Let's review the facts:

1) The BSD license (and similarly liberal licenses) promotes freedom for everybody, while the GPL goes out of its way to restrict freedom (namely, the freedom to not redistribute modified code).

2) The BSD license is used by developers who are interested in creating high-quality software, rather than partaking in ideological squabbles.

3) The BSD license is attractive to commercial users, who often provide very valuable financial and personnel support, and who still end up contributing their work back to the community.

4) The BSD license is being used by more and more of today's new, successful projects. This is because it promotes free collaboration, rather than forced collaboration.

So after reviewing the facts, it is clear that the BSD license and other liberally-minded licenses are the better options. They maximize freedom, they allow for true cooperation, and they avoid petty academic shenanigans in favor of getting real work done.

Re:BSD

[thatkid_2002]

Ah I remember when I was young and things were this simple.

Re:BSD

[Anonymous Coward]

I can take someone else's free work, add my own piddling little contribution, close the source and sell the binaries! Profit!

Re:BSD

[Anonymous Coward]

What I've seen is companies make their own extensions, don't distribute, and then get stuck on old compilers due to GPL

Re:BSD

[Anonymous Coward]

If your contribution is in fact piddling, I'll take the free version rather than pay you for your binaries. --Profit!

Re:BSD

[Anonymous Coward]

Attaching the compiler libraries to a closed source IDE.

Re:BSD

[Anonymous Coward]

You go try that and see how that works out for you.

Re:BSD

[larry bagina]

You can freely distribute clang. You can contribute back to clang. It's probably easier to contribute back since the code isn't a monolithic mess.

It makes no difference to me as a user whether my compiler is GPL or BSD licensed. But those license decisions affect the compiler architecture which affects the compiler. Clang/LLVM are modular for technical reasons. They don't care if you "steal" a component. GCC is monolithic for political reasons. RMS is afraid you'll use it without giving back. What if you want to use a real C++ parser and auto completer in your text editor? Clang is fine with that. GCC was designed to prevent you from doing that. What if you want to generate javascript from your C++ parse tree? Clang is fine with that. GCC was designed to prevent you from doing that.

Re:BSD

[TheRaven64]

The GPL might encourage that, in theory, but it doesn't in practice. For example, take every MIPS vendor ever. They start with GCC, and then hack it up to support their extensions. In the process, they break every other MIPS target, so their extensions are never pushed upstream. They ship their GCC version to their customers, who are then stuck with an old implementation, with support for old language dialects. This is even worse for supercomputers, with a typical operational life of a decade or so. There are still IBM supercomputers in service that ship with a hacked-up gcc 2.95. This is why there's a lot of interest in BlueGene/Q support in LLVM: it is upstream and the vectorisation support is all in the target-independent layer, so keeping it up to date is simple.

Re:BSD

[DarkOx]

1) The BSD license (and similarly liberal licenses) promotes freedom for everybody, while the GPL goes out of its way to restrict freedom (namely, the freedom to not redistribute modified code).

The only freedom this limits in practice use is the freedom to profit off the work of others. I am not a supported of IP as a concept in general but it exists; to that end GPL has succeeded in ensuring there is a workable free ecosystem that I really don't think would exist with out it.

2) The BSD license is used by developers who are interested in creating high-quality software, rather than partaking in ideological squabbles.

So people who are not interested in licensing considerations don't think about it much; a tautology.

3) The BSD license is attractive to commercial users, who often provide very valuable financial and personnel support, and who still end up contributing their work back to the community.

This is true of the GPL and LGPL as well; both of which ensure that those commercial users actually do give back where the BSD and like licenses don't.

4) The BSD license is being used by more and more of today's new, successful projects. This is because it promotes free collaboration, rather than forced collaboration.

Yes and this is really unfortunate. Just like at all the time and energy wasted unlocking devices and such. I think its really to bad Linus did not take the kernel GPL3; if he had the droid ecosystem would actually be open. Your BSD licensed compiler sure will be great when you and I can't find a hardware platform to run it. Tivoization is quickly going to ensure that having free software will be of no use because all you will never be able to use anything but someone else signed binary blob anyway.

Re:BSD

[pavon]

Well the GPL specificly isn't a problem here, however it is really nice to have an alternative to GCC that actually encourages and facilitates reuse of their code rather than one that puts up deliberate obsticles to reuse even by other free software projects.

One of the big reasons that CLang was created was because there were some free software developers that wanted to integrate high quality front-ends (parser, etc) into other projects like IDEs, LLVM, and such. They prefered to work together with GCC to share the effort, but GCC refused. They were so paranoid about proprietary applications using GCC code that they refused to seperate the front-end into a GPL library that GPL applications could use. Their rational was that someone could easily write a GPL wrapper application around that GPL library that just serialized the data to/from a text representation, which could then be legally used with a proprietary application. In their mind, it was more important to make it difficult for proprietary applications to use their code than to make it easy for free software to use their code.

So LLVM was forced with the decision to either fork GCC or write their own. GCC was never designed with front-end modularity in mind, and a lot of changes would be necessary to do so. Once that massive refactoring was complete, it would be difficult to share improvements between the two codebases. Between that and some compelling technical reasons they chose go write their own and CLang was born.

Re:BSD

[kthreadd]

Maybe the IDE vendors should release their software under a compatible license. Profit!

Re:BSD

[mark-t]

GPL goes out of its way to ensure that absolutely *everybody*, so long as copyright law is being adhered to, will have the exact same freedoms as any previous developers do. GPL tries to ensure freedom further downstream at the cost of some freedom for developers along the way, while BSD only tries to keep itself as free as possible at the originating work, at the potential cost of some freedoms for developers further downstream from the originating work.

Neither option is always suitable for everybody... and I wouldn't argue that either is really more free than the other.

Re:BSD

[Anonymous Coward]

then you got older and developed a case of mental retardation

Re:BSD

[Anonymous Coward]

GCC is monolithic for political reasons. RMS is afraid you'll use it without giving back.

That's certainly one of his more "questionable" decisions, but it's not because of the GPL per se, it would be perfectly possible to write a modular GPLed compiler, just as there's plenty of modular GPLed software of other types.

Re:BSD

[Anonymous Coward]

How does forcing someone to give away their source count as 'freedom'. Any time you force someone to do something there is no freedom. Oh, so you will say, "don't use GPL source if you don't want to be forced to give your code away." That is already putting a constraint on things. Apache is a thriving community that produces high quality code (even if it has the shittiest documentation ever). It is definitely on the BSD side of things. In either Apache or BSD, I cannot see any cost of freedom further downstream. The derived code from later programmers is not the issue. The issue is the code you are open sourcing. It is either truly open or it is not. That is why later programmers have more freedom. They have the freedom to open source their changes or not. While the GPL side gives no freedom. You must give away your code and short circuit any chance of making a living from your work. But I see you're from B.C. Probably work for the government or a college or university, and vote NDP. No understanding of real work.

Re:BSD

[Microlith]

I hate feeding worthless trolls, but here goes anyway:

How does forcing someone to give away their source count as 'freedom'.

You aren't forced to give away your source. If you're going to make modifications to GPL code, you should be fully aware of what the terms of redistribution are. Anything else means you're a damned, willful fool.

Oh, so you will say, "don't use GPL source if you don't want to be forced to give your code away." That is already putting a constraint on things.

And? Don't enter a contract if you don't want to be bound by its terms.

In either Apache or BSD, I cannot see any cost of freedom further downstream.

Are you the sole arbiter of such things?

The derived code from later programmers is not the issue.

It is, from the perspective from the GPL.

While the GPL side gives no freedom.

On the contrary, the GPL guarantees freedom. You cannot receive a modified copy of a GPL program without also receiving the sources in their entirety.

You must give away your code and short circuit any chance of making a living from your work.

Oh good, you preserved this little lie.

But I see you're from B.C. Probably work for the government or a college or university, and vote NDP. No understanding of real work.

Typical trolling AC, leading on for a while and blow it with a personal attack.

Re:BSD

[Anonymous Coward]

The same benefits apply to the BSD license as the GPL. Users and developers can freely distribute Clang, people can contribute back, etc. The added benefit is the BSD license is less restrictive and that allows other projects to freely link to BSD-licensed code without adopting the restrictions which go hand-in-hand with the GPL. A BSD-licensed compiler can also be included in projects, like FreeBSD, where a more liberal license is required.

Re:BSD

[phantomfive]

For Apple it started to matter as soon as GCC went to the GPL 3.0. They didn't want to be at risk of giving out their patents, so they switched to CLANG, which is BSD, since they were modifying the compiler.

For most of us it doesn't matter at all.

Re:BSD

[SuperKendall]

Ah I remember when I was young and things were this simple.

Well I am older and with age comes clarity. His points on why BSD is now a preferred license are exactly correct.

Re:BSD

[Anonymous Coward]

Please refrain from using ad hominem attacks here. There's no need for petty name-calling using terms like "worthless troll" or "trolling AC". We discuss topics in a civilized, mature manner here.

Re:BSD

[SuperKendall]

The only freedom this limits in practice use is the freedom to profit off the work of others.

Why is that so bad? If I'm writing code to share, I want others to use it. In that sense they are profiting, with code that works better/is more popular/comes out sooner. Just because some people ALSO profit monetarily should not matter to me in the slightest, again I am just happy someone could use the code I wrote.

I am not a supported of IP as a concept in general but it exists; to that end GPL has succeeded in ensuring there is a workable free ecosystem that I really don't think would exist with out it.

There are countless existing examples showing it does work: BSD UNIX itself, Webkit, and the very Clang under discussion. It is crazy to claim it does not work. Just because the GPL works fine as designed, does not mean a BSD approach cannot ALSO work.

So people who are not interested in licensing considerations don't think about it much; a tautology.

No; people who are not interested in the political aspect of licenses are forced to think about it anyway. By choosing BSD it reduces the amount of thought put into the license to the minimum, because it is the one with the greatest political freedom.

This is true of the GPL and LGPL as well;

As someone who writes some commercial software it is NOT true of the GPL3. It is true of the LGPL - which is why the FSF is trying to get rid of it.

both of which ensure that those commercial users actually do give back

No they don't. They just ensure that someone COULD legally go after them. But there are lots of violations we already see all over the place. As a company choosing the BSD is useful because you can be sure you are not in violation if someone forgets to contribute code back.

People in companies who change open source code contribute back not because of the license, but because they don't want to risk changes being over-written in the future when updates are applied. It's (a) extra work and (b) (far more likely) something that has to be remembered or become process. Either way it's very likely that in a few years someone will forget and then disaster will follow. So companies have natural motivation far greater than the legal motivation to contribute source back.

Yes and this is really unfortunate.

In no way is it unfortunate. It's a good thing for ALL open source licenses that more people are comfortable using and sharing force.

To start with, the GPL was needed to get people generally understanding that code should come back, and to provide some solid bases of code that were free. But at this point, the BSD is more useful to more fully open up companies to using open source in everything. Then after some time, the GPL can come into wider play again when companies understand that sharing source code works for everyone. So at this point BSD is doing more to help GPL than the GPL itself is.

Re:BSD

[Anonymous Coward]

The problem is that they don't think they can profit from that so they don't.
In the end that leads to a lot of software not being developed rather than IDE's being release under open source.
BSD license still doesn't prevent anyone from doing updates and the releasing the source so there won't be any reduction in then number of open source IDE.

Re:BSD

[BitZtream]

The only freedom this limits in practice use is the freedom to profit off the work of others. I am not a supported of IP as a concept in general but it exists; to that end GPL has succeeded in ensuring there is a workable free ecosystem that I really don't think would exist with out it.

How incredibly shorts sighted and ignorant of you.

If the say ... the standard IP implementation that ... EVERYONE ON THE FUCKING PLANET users was GPL'd instead of BSD'd ... then we would have unique IP networking implementations across every OS on the planet, assuming that the Internet would exist yet in the first place since Cisco isn't going to jump on your GPL'd protocol since they can't do nearly as much neat tricks to make them a viable company.

Its sad that you don't realize what a chilling effect GPL has on software acceptance.

You fail to understand that shared standards are what makes computing work. I'm sure you'll scream OPEN STANDARD and then that actually means GPL style standards. So instead of being open and working with others, you want everyone else to play the same way you do. If they don't, you take your toys and go home.

Spoiled brats, the entire lot of you.

Re:BSD

[Anonymous Coward]

's a sad thing the principal always forced bullies to give up their freedom and stop hanging you upside down in the locker room on your pants belt, your brains could use better blood flow.

Seriously now, "They are taking away my freedom of taking away freedom from others!!111"?

Re:BSD

[BitZtream]

BSD in no way takes options away downstream.

Everyone will have access to the BSD code.

You may not get access to some new code that was combined with it ... but that code was never BSD code ... you never had access to it ... nothing was 'taken away from you' because you didn't have it in the first place.

GPL doesn't 'keep people from taking things away from you' it forces them to give it to you.

If you think GPL is about freedom, why is it such a long list of restrictions compared to AT WORST, the 4 a BSD license carries (now days everyone uses only 2). I can handwrite the BSD license in a minute or so ... I think my printer would run out of ink if I tried to print a copy of the GPL in standard font right now.

It really is mind boggling how you can talk about freedom which is so obviously not.

Re:BSD

[Microlith]

we would have unique IP networking implementations across every OS on the planet

We do, actually. The BSD TCP/IP stack isn't actually a part of windows.

Its sad that you don't realize what a chilling effect GPL has on software acceptance.

None? Or do you mean, "acceptance by companies that are willing to take but unwilling to contribute"?

Spoiled brats, the entire lot of you.

Care to come back when you're capable of coming up with an actual point rather than a spittle-flecked rant with little substance?

Re:BSD

[BasilBrush]

Well they didn't exactly "switch" to Clang. They created Clang.

Re:BSD

[K. S. Kyosuke]

If the say ... the standard IP implementation that ... EVERYONE ON THE FUCKING PLANET users was GPL'd instead of BSD'd ... then we would have unique IP networking implementations across every OS on the planet

First of all, we do have unique IP networking implementations across most OSes on the planet.

Second, the spread of that particular implementation was a disaster anyway because the BSD sockets interface sucks. Ever seen Plan 9 interface? But no, now we have a "universal" API...doesn't matter that it sucks, as long as it's "universal". ...or not?

Re:BSD

[BasilBrush]

As anyone who reads the thread can see, it's inspired a good discussion, with a lot of people on both sides making good points. The best of which is SuperKendall's post ripping you and your attitude to pieces for the ignorance it is.

Re:BSD

[Anonymous Coward]

Please refrain from using ad hominem attacks here. There's no need for petty name-calling using terms like "worthless troll" or "trolling AC". We discuss topics in a civilized, mature manner here.

It is not name calling it is stating an obvious fact. If you want to complain, complain about him stating the obvious.

Re:BSD

[AaronW]

I work for a MIPS vendor (Cavium) and I know we push almost all of our extensions upstream and we ship very recent versions to customers. We're currently shipping 4.7 to customers. This includes support for the Cavium OCTEON proprietary assembly instructions as well (encryption, hashing, load/store indexed and atomic instructions). There is a lot of active GCC development where I work and in fact we are looking for more GCC developers for both MIPS and ARM.

Similarly we work hard to push all of our stuff upstream to the mainline Linux kernel.

I need to work on pushing up our U-Boot bootloader support after I migrate to GIT though that's going to be a huge project since we have more code for our SOC than any other vendor out there.

Re:BSD

[Anonymous Coward]

That's where OS X came from, right?

Re:BSD

[cheesybagel]

There are countless existing examples showing it does work: BSD UNIX itself

You are joking right?

Webkit

Which is based on LGPLed KHTML.

Clang

Which remains to be seen in the long run. Plus it still produced slower x86 code than GCC last time I tried.

Re:BSD

[colinrichardday]

GCC is monolithic for political reasons. RMS is afraid you'll use it without giving back.

How does the design of GCC prevent anyone from *using* it without giving back?

Re:BSD

[Billly Gates]

Which is why the BSD license is so supperior. I wished FreeBSD 5.x didn't crumble and would beat linux. :-(

What is so damn evil about making money? WHat is so evil about feeding your family? Sorry but the world will not go into a communistic way of life and not use things which help consumers and businesses alike such as Office, sharepoint, ERP apps, games, or whatever. Sure you can use GNU but who do these people are to prevent businesses to streamline their processes with software or to tell us we can't have dreams of a better life by writting the next killer app?

This is not offtopic here, as GCC has clearly stated its goals were to prevent this now that they are popular. Well guess what? I see this no different than Microsoft of the old days which become popular on the cotails of another master (IBM) who then dictated which standards, versions, products, and other things at the OEM level. It is the reason we still have IE 6 in use today. GCC is no different as they are using whatever means necessary for the agenda. Just on hte opposite side of the socialism/capitalism scale. What we need is no politics or agendas and just use a product.

Re:BSD

[dottrap]

In fact, the harm caused by gcc being GPL was the very reason Clang was invented.

The political motivations behind GPL forced gcc to be developed in such a way that it was monolith and impossible to build more advanced tooling that needed data from the intermediate stages of the compile process.

See Chandler Carruth's talk "Clang: Defending C++ from Murphy's Million Monkeys". At the beginning between 2:20 and 4:00, he quotes Richard Stallman's response to their proposed changes and demonstrates that using gcc is a non-starter.

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys

Re:BSD

[Billly Gates]

So you feel they have a right to dictate to other users what they can do with their computers? Who do they think you are? Microsoft of old?

If someone wants to make money why should the compiler stop them? If someone wants to purchase software why should we stop them? What is so wrong about someone having a dream for a better life who wants to feed their kids?

Ide's want more integration, more apps want to make extension without giving away their trade secrets, more embedded devices want and need a compiler. It is hypocrtical for people like RMS to claim not to touch computers with non-free software as they take away freedom, yet work on products that do take away freedom from its users and yes developers who write commercial software use compiler and they have freedom too to feed their families and own homes and cars like everyone else.

GPLv3 has some real problems and htis is one of them. Slashdot 12 years ago was very anti-capitalistic as many of us were college students/basement dwellers. Now we are grownups with bills to pay. This silliness needs to stop and yes you are free not to use my software if I decide to charge for it so there you go.

Re:BSD

[Jeremi]

Or do you mean, "acceptance by companies that are willing to take but unwilling to contribute"

There's nothing intrinsically wrong with being willing to take but unwilling to contribute, as long as the software's author is okay with that. Since software is free to replicate, it doesn't hurt the software's author or anyone else if a company uses it, and it might even help (e.g. if more companies use the software, it allows the software to be more thoroughly tested and debugged, and may help it become a de facto standard).

That said, if the author of the software doesn't like "freeloaders", the author can license under the GPL instead. Different strokes and all that.

Re:BSD

[Anonymous Coward]

One point has to be made. The BSD people prefer compilers being also BSD licensed. This way the compilers are likely to attract a more varied user community, which should in turn lead to better portability.

Re:BSD

[MikeBabcock]

Yawn, perspective issues.

The BSD license provides freedoms that can restrict others' freedoms (1).

The GPL allows only freedoms that keep everyone on an equal footing (2).

Pick your poison and stop spreading FUD.

1) If I take your BSD code and make a device that uses it, then stop supporting said device, you have no right to the changes I made to that code to fix bugs yourself in the future. You have less freedom than if it were GPL code.

2) If I want to use your GPL code, I have to also license the rest of my linked code GPL and thus lose my right to distribute my own code more restrictively.

Nothing is wrong with either of these things, but BSD people like to ignore the first, and GPL people like to ignore the second. Again, its all about perspective -- I prefer the GPL as a user. Every time.

Re:BSD

[MikeBabcock]

How many devices do you own with modified BSD licensed software on them that you can't fix because those changes are unreleased?

More importantly, how would you know?

Re:BSD

[SuperKendall]

How many devices do you own with modified BSD licensed software on them that you can't fix because those changes are unreleased?

The point is the devices exist, and would not as they are without BSD. The GPL equivalent would not have simply have supplanted BSD.

As for "being able to fix them" I could certainly fix the BSD aspects of any of them.

More importantly, how would you know?

Know what? That's awfully broad. Know that they use BSD? You forget the licenses do generally require disclosure of use. Know that they are broken? Seems like that would be apparent if it was enough of a problem to matter.

Re:BSD

[mark-t]

Only the original work. Derivative works are not necessarily guaranteed to be just as free. The point of the GPL is to ensure that people further downstream from the original work will have access to whatever work they end up with as well.

Re:BSD

[Anonymous Coward]

SuperKendal moderated to +5. You? Only +2. Fuck off, zealot. Go shill some more and maybe Stallman will let you suck his crusty dick. Faggots like you support the GPL to earn sexual favors from that fat bastard.

Re:BSD

[mark-t]

Nobody's forcing you to use the GPL if you think it's unsuitable for you, but really, the GPL is only trying to offer its freedoms to people who may be further removed from the original work, while BSD only offers its freedoms to immediate developers (who admittedly have an additional freedom to exclude people that they distribute to from having the same freedoms on any derivative work that they provide, while the GPL does not offer developers this freedom at a;;).

BSD is about something being free right now, but future versions of the software developed by other parties who may not agree with those terms could alter that arrangement. That the original source may be available doesn't make any modified future versions where the source has been closed up more free than they are. GPL is strictly about *keeping* something free, for as long as the copyright on the work lasts, at the costs of some freedoms for developers of derivative works. BSD is about something being free right now, and letting market forces alone determine whether the source code of future versions will continue to be available.

Re:BSD

[Anonymous Coward]

What exactly is the advantage of a BSD license for a compiler?

Shader compilers in proprietary drivers.

Re:BSD

[smellotron]

While you're at it, please denigrate PostgreSQL as well.

Re:BSD

[Anonymous Coward]

There's a not so minor problem implied in 1) that may be a typo, or it may be due to the misunderstanding that other posters have expressed.

The GPL says that when you (party A) distribute GPL licensed code to party B, in any form, you must make the source code in the preferred form available to party B. It does NOT require that you give source to anyone else, including any upstream authors.

To reiterate, neither the BSD or GPL license require distribution of code upstream.

Re:BSD

[TheRaven64]

You might want to look at LLVM a bit more closely, as Juniper, which ships a pretty large number of your chips, is about to start their GCC to Clang migration in the next few months...

Re:BSD

[thatkid_2002]

For those interested, phatomfive is referring to this: http://fsfe.org/campaigns/gplv3/patents-and-gplv3.en.html#Explicit-patent-grant in regards to GPLv3 and patents.

Re:BSD

[Anonymous Coward]

it is well known that RMS has refused modules in GCC. he refused exporting XML represent stations of c++ code since it could help non-gpl software.

Re:BSD

[Anonymous Coward]

As someone who writes some commercial software it is NOT true of the GPL3. It is true of the LGPL - which is why the FSF is trying to get rid of it.

The FSF is not trying to get rid of the LGPL. RMS says:

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.

Re:BSD

[Guy Harris]

What is so damn evil about making money? WHat is so evil about feeding your family?

Nothing. However, if making money to feed your family means using somebody else's GPLed code and not making the source to your project available, or using somebody else's GPLed or LGPLed code, with your own modifications, and not making the source to the modifications available, you should consider finding some other way to make money to feed your family. The author of the GPLed or LGPLed code is under no obligation to make it easier for you to do so.

Sure you can use GNU but who do these people are to prevent businesses to streamline their processes with software or to tell us we can't have dreams of a better life by writting the next killer app?

You can do both. Just don't, in the process, use other people's code in ways that they don't wish it to be used.

It's time to move on from GCC.

[Anonymous Coward]

GCC has served us well over the years. Much of the open source community's success can be attributed to GCC. But times change, and we must change with the times.

It is now time for GCC to go. LLVM and Clang are clearly the future. While GCC will linger for some time, it is obvious that LLVM and Clang are the technologically-superior choices. They offer better, freer licensing. Their code is much cleaner. They offer a path to the future. The community has a vibrancy that we just don't see in the GCC community.

FreeBSD, which has always been a leader among the major open source projects, has done the right thing and adopted LLVM and Clang. Now it's time for the major Linux distributions to do the same.

The LLVM and Clang future is bright. It is much, much, much brighter than the GCC future, in my opinion.

Re:It's time to move on from GCC.

[cheesybagel]

Even if Clang was immensely successful it does not mean GCC would go away. Not anymore than having Chromium stopped people from using Firefox.

Re:It's time to move on from GCC.

[cpghost]

While I agree that LLVM and Clang are superior, technologically and developer community-wise speaking, having multiple C++ compilers can actually improve client code quality. Right now, most OSS developers are using some GCC-isms in their code, knowingly or unknowingly, and when confronted with compiling that code with Clang, they realize just how far they left the C++ standard. Keeping more than one compiler implementation around and using them concurrently is always a good thing, IMHO.

OpenMp

[darkHanzz]

It would be so nice if they added OpenMp support. It's an awesome compiler, but due to lackin OpenMp currently not so suitable for cross-platoform number-crunching.

Re:OpenMp

[Anonymous Coward]

OpenMP is unsuitable for number crunching.

Re:OpenMp

[Anonymous Coward]

OpenMP is unsuitable for number crunching.

[citation required]

Re:OpenMp

[Anonymous Coward]

here

Re:OpenMp

[Anonymous Coward]

OpenMP is just fine if your number crunching is just going over an array.

Re:OpenMp

[TheRaven64]

It's being worked on. There are patches from Intel that add support, but they're currently under review. There was a big discussion at the last LLVM DevMeeting about the correct way to add support. GCC adds the calls to the OpenMP runtime library very early on in the compile pipeline, which destroys a lot of potential optimisation opportunities. The goal with LLVM is to preserve the parallel loop structure through optimisations and then insert the calls out to the runtime library much later on.

More complete?

[goombah99]

How can something be more Complete? I can understand less complete. Does this imply knowledge of the future?

Re:More complete?

[Anonymous Coward]

It means that they're not sure since it hasn't finished compiling yet.

Re:More complete?

[Anonymous Coward]

The "more" is part of the English expression "more or less", which means "nearly". It wasn't used as modifier to the word "complete".

Re:More complete?

[Anonymous Coward]

Or it means that it's incomplete, but closer to completion than that which is less complete.

Re:More complete?

[AmiMoJo]

This kind of comment is what keeps me coming back to /.

- It's pedantic
- The editors never edit out basic typos, let alone subtle grammar or phrasing
- It's the first post to be modded up
- You must be new here

Thanks goombah99, keep up the good work!

Re:More complete?

[AmiMoJo]

P.S. Sheldon Cooper is that you?

Re:More complete?

[Anonymous Coward]

How can something be more Complete? I can understand less complete.

You just answered your own question. More complete means that the version it's being compared against is less complete.

Re:More complete?

[Anonymous Coward]

But something can be 50% complete.
Wouldn't something that is 60% complete be more complete than something that is 50% complete?
Complete, just like full is a state that something can go to. The change can be gradual. (Or has to be if you don't believe in discrete time.)

What something can't be is more than completely full or more than fully complete.

Executable performance

[Excelcia]

I'm not so concerned about C++11, or compiling speed - which is what most people tout about LLLVM as its big feature. I'm concerned about the quality of the binaries produced. LLVM produces generally inferior code to GCC, which itself is already quite inferior to MSVC. I just wish there was an open source compiler where binary performance was a primary concern, not an afterthought.

Re:Executable performance

[Anonymous Coward]

Compiled code from llvm is on par with gcc. In some cases faster in other cases slower.

Re:Executable performance

[Anonymous Coward]

Do you know of any specific optimizations that MSVC does that the others do not? Just curious.

Re:Executable performance

[KiloByte]

From my own benchmarks, clang behaves like gcc at one optimization level lower, both for compilation speed and speed of the resulting binary.

It's support for C++ has been rife with bugs, but things have improved a lot, so clang gets roughly close to gcc (other than highest, rarely used levels of optimization), except for two areas: warnings (clang produces tons of bogus ones), and portability (clang supports only i386, amd64, 32 bit arm, big-endian mips, s390, while gcc does pretty much everything).

Re:Executable performance

[Anonymous Coward]

In my benchmarks llvm is universally faster.

And you missing a ton of platforms that clang supports.
http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp

Re:Executable performance

[Excelcia]

I wish I knew what specific optimizations give MSVC its performance gains. What I do know is that it''s not trivial. For encryption and compression libraries, MSVC compiled libraries give me a 20% speed gain over GCC. I really want to supply my projects built with a completely open-source tool chain, but I can't justify taking that kind of performance hit for that.

I suspect MSVC produces better performing code less because of any one particular optimization and more because it is way more tightly coupled with the x86/AMD64 architecture. Most open-source compilers are three stage. Front end (language), a (generic) optimizer, and the back-end machine code emitter. The front end and optimizer stages don't know what sort of code will be emitted, so they can't make any assumptions. Does a particular construct cause cache misses? Does it invoke Intel's replay system? They don't know or care. It's only the emitter at the very last stage that is processor-aware, and by then there is only so much you can do. MSVC, on the other hand, is processor-aware from stem to stern. It can make CPU-specific assumptions at a very early stage and can take far greater advantage of SIMD instructions.

Compilers were much better when each one was for one architecture only. When they didn't mess around with intermediary bytecode, and were intended to one thing only - take language X and turn it into machine code Y.

Re:Executable performance

[Anonymous Coward]

The kind of % difference you report is similar to what I get in a computer graphics application with heavy use of SSE. I always attributed that to the close relationship between the MSVC and Intel compilers, and the Intel compiler produces the fastest code for x86. LLVM is new and has a lot of catching up to do and for x86 it will probably never be as good as Intel's or MSVC due to different priorities.

Re:Executable performance

[iggymanz]

eh, gcc doesn't even follow C99, it's a half-assed C89 with all kinds of weird extension. its middle layer is intentionally left opaque and undocumented by Stallman's minions, totally against the open source spirit

Re:Executable performance

[Anonymous Coward]

You can still do a lot of optimization outside of the compiler by tweaking the run time libraries to your architecture.
Most of the time compiler produces worse code than optimized machine code for very simple functions (e.g. below 10 to 20 lines). This is also the complexity of some of the more frequently used library functions. The gain diminishes as the compiler is pretty good for functions with a higher complexity.

Re:Executable performance

[Anonymous Coward]

Have you tried "gcc -std=c99"? Just asking.

Re:Executable performance

[Anonymous Coward]

There is no good reasion for gcc to default to c89 in 2013.

Re:Executable performance

[Anonymous Coward]

Yes, this is not true c99.

Re:Executable performance

[cheesybagel]

Man that code is god awful. The most special cased POS I have seen in a long time.

Re:Executable performance

[cheesybagel]

Even better "gcc -std=gnu99". I use that one.

Re:Executable performance

[Jeremi]

The most special cased POS I have seen in a long time.

To be fair, any compiler is eventually going to end up reflecting the qualities of the language it is compiling. :P

Re:Executable performance

[spitzak]

You might want to try the Intel compiler. This was three years ago but it produced obviously faster results than either gcc or msvc.

Re:Executable performance

[Guy Harris]

eh, gcc doesn't even follow C99, it's a half-assed C89

Are there any issues other than those mentioned in the GCC developers' status of C99 features in GCC page?

with all kinds of weird extension

Well, yes, if you specify --std=c99, "When a base standard is specified, the compiler accepts all programs following that standard plus those using GNU extensions that do not contradict it." You'd need -Wpedantic to get warnings about all GNU extensions and -pedantic-errors to get them as errors.

Re:Executable performance

[Guy Harris]

In my benchmarks llvm is universally faster.

And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp

By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.

The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").

So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)

Re:Executable performance

[Anonymous Coward]

As the other poster says, try ICC. I spent a few days a month or so ago studying the output of GCC and ICC for some code I was compiling where it was literally running 50% faster with ICC vs GCC.

What It appears is that ICC has a much better model of icache, and instruction latency and throughput. This seems to allow it to make much better scheduling choices. For example loop unrolling. The decision about when to unroll a loop is full of tradeoffs having to do with fetch latencies, how many times your in the loop, register pressure as well as dependencies from one loop iteration to the other.

I saw a case where ICC noticed the result of a previous iteration wasn't ready by the time it was needed in the next cycle avoiding a dependent stall, so it unrolled an extra iteration of the loop and added code to combine the result later on. Playing around with the code, the number of iterations it were pretty much spot on for hiding most of the dependent latency. Changing the arch type was changing the unroll depth too. In all I was pretty impressed.

Re:Executable performance

[Anonymous Coward]

Clang supports every backend that llvm does. What it doesn't do is automaticity find all the libraries and header files that are standard for a plat form. But you can specify any target that llvm supports.

GCC doesn't support all those targets because they need to be explicitly included in at compile time.

Re:Executable performance

[Guy Harris]

Clang supports every backend that llvm does. What it doesn't do is automaticity find all the libraries and header files that are standard for a plat form. But you can specify any target that llvm supports.

GCC doesn't support all those targets because they need to be explicitly included in at compile time.

By "targets" do you mean "instruction set architectures" or "ISA version + OS"?

And by "support" do you mean "if you build GCC it automatically includes support for all those targets without having to configure them in" or do you mean "allows support for that target to be compiled in"? If you mean the former of those two definitions of "support", that's not generally what "support" means in this context; if you mean the latter, well, which of "X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore" aren't supported? On the host/target specific installation notes for GCC page, I don't see any explicit mention of Thumb, CellSPU, MSP430, or XCore ("SystemZ", i.e. z/Architecture or "64-bit System/3x0", is called "s390x" on that page), although the ARM options page for GCC mentions Thumb; I see references on the Web to an "mspgcc" project for the MSP430, but it's not part of the GCC release, and I see mentions of an "spu-gcc", but nothing about Xcore.

Re:Executable performance

[Anonymous Coward]

If you are not concerned with compiling speed, GCC 4.8 using -O0 is the tool for you. 100x slower than GCC 4.4 -O3 on my applications (clang is 2x faster than GCC 4.4).

Re:Executable performance

[iggymanz]

yeah, it almost works

Re:Executable performance

[Anonymous Coward]

I really want to supply my projects built with a completely open-source tool chain, but I can't justify taking that kind of performance hit for that.

Why?

Re:Executable performance

[alexo]

While the latest MSVC produces fairly optimized x86 code (second to Intel's compiler), it's C++11 standard compliance is lacking.

See:
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

I had high expectations when Herb Sutter went to work for Microsoft but, so far, I am disappointed.

This Entire Thread

[interval1066]

I'm having a hard time sorting the bs from the gems here. Every post is questionable. Thanks /.

Re:This Entire Thread

[Anonymous Coward]

Hmm, there don't seem to be a lot of top posts at default viewing level.

Re:This Entire Thread

[mevets]

Ironically mirroring gcc itself....

Is there an in-print specification of C++11?

[mark-t]

Like, has a new edition of The C++ Programming Language come out to reflect C++11, and all of its changes? Or are the only complete specifications purely online?

Re:Is there an in-print specification of C++11?

[Anonymous Coward]

C++2011 being an ISO standard you probably can buy the paper standard at your national standard organization (ANSI in the US, AFNOR in France, etc.). But it it quite costly.

Re:Is there an in-print specification of C++11?

[Anonymous Coward]

From ANSI it should be affordable. Final drafts are free, and good enough for many uses.

Re:Is there an in-print specification of C++11?

[Anonymous Coward]

Chances are that if you're an early adopter you'll find enough documentation in StackOverflow.

captcha: instruct

Re:Is there an in-print specification of C++11?

[Fei]

The fourth edition of The C++ Programming Language with c++11 coverage will come out next month. (ISBN: 978-0321563842)
There are already general books on c++ that cover the new standard, like C++ Primer 5th edition.

Re:Is there an in-print specification of C++11?

[Anonymous Coward]

Well, supposedly. The release date has changed numerous times, from March to June to May. Book release dates these days are elastic, to say the least. I've wanted this book for a long time, and it's becoming a saga as to when it'll be released.

If you can't wait, both Lippman's and Prata's primers are updated for C++11. Lippman is more "pure" C++ and Prata is more from a C background. I like Prata's book because there is a single chapter with all the new stuff.

Oh, and ... Herb Schildt is waiting until 2014 to update his C++ books. Wonder if they'll have a bibliography citing all the C++11 books that have come out since then?

Re:Is there an in-print specification of C++11?

[Anonymous Coward]

C++ specifications are never freely downloadable. Seriously, they want you to have to pay for book, or pay for right to download.

Just use torrent.

Re:Is there an in-print specification of C++11?

[kthreadd]

Looks like it's down to $ 30.
http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS/ISO/IEC%2014882-2012

Sometimes I just don't get Slashdot mods...

[Anonymous Coward]

So a large company with lots of resources has made some very helpful contributions to an open source project.

That open source project has prospered, providing extreme benefit to users far beyond the company that made the significant contributions.

Projects as diverse as FreeBSD and Rust, among many others, have benefited hugely from Clang and LLVM.

The end result is so useful that it even threatens a long-time, well-established incumbent like GCC.

Yet somehow a Slashdot poster who merely acknowledges these contributions ends up modded down to -1? It's absurd.

The OSS community has been desiring more contributions for decades. When people and organizations with the deepest pockets do contribute, those who recognize this and express gratitude are shunned. It's just so absurd.

Re:Sometimes I just don't get Slashdot mods...

[Anonymous Coward]

It's modded down because of lack of getting the whole picture. Apple stabs the free and open source community every single day. Occasional goodness does not undo the apparent evil that that company stands for. That's why it's modded down. It's simply just bad taste.

Re:Sometimes I just don't get Slashdot mods...

[Em Adespoton]

That would probably hold more weight not coming from AC.

It all has to do with the framing of the situation.

Let's see how it does coming from me...

I think it's great that Clang and LLVM are doing so well in this space, and applaud Apple, Adobe, Google, and all the other corporations who have contributed to it to get it to this point.

I'm also glad that GCC continues to exist and to progress. Diversity is good; people can choose the permissivity of their license, and choose the openness of their platform; there's a nice wide choice of options now.

Probably what the GP meant as well, but how they phrased it could really annoy a lot of people who interpreted it differently. Some people don't like it when others thank corporations/people for doing something that has benefited all, when they can see satellite issues that are to society's detriment in the long-run.

Personally, I find that the best way to get people/corps to do what you want is with a carrot and a hackamore -- leave the stick alone.

Re:Sometimes I just don't get Slashdot mods...

[PhamNguyen]

Betteridge's law of mods: By the time you get to a post compaining about a -1 score of its parent, the parent has already been modded up to "(3) insightful".

AGPL: your rights to someone else's....

[unixisc]

AGPL is GNU banditry of the ultimate order. If you don't buy software to use on your own computer, but simply run the services that they offer on their servers, this license would mean that you get to see, use and distribute their source code. That's even more insidious than GPL. At least GPL was talking about what you get from someone else to use on your computer - something that's actually been given to ya But AGPL is about you getting the nuts & bolts of something that you're just renting, not even owning. But sure, all pro-RMS freeloaders, feel free to go and demand that people who offer software as a service on their own computers and ain't giving you anything, other than the use of their hardware, give you the source code to the services they run for ya. That's a great idea!

Re:AGPL: your rights to someone else's....

[Microlith]

If you don't buy software to use on your own computer, but simply run the services that they offer on their servers, this license would mean that you get to see, use and distribute their source code.

Well, it is GPL software and it is effectively being redistributed to 3rd parties.

all pro-RMS freeloaders

Oh good, we've devolved into petty name-calling already!

But sure, all pro-RMS freeloaders, feel free to go and demand that people who offer software as a service on their own computers and ain't giving you anything, other than the use of their hardware, give you the source code to the services they run for ya. That's a great idea!

I'm sorry, since when did it become such a noble cause to want to defy the spirit of the GPL, and then whine and gripe when it goes from spirit to legal fact? Again, you have to know the license of the software you're modifying before you go and do so, otherwise you're a damned fool.

Re:AGPL: your rights to someone else's....

[BitZtream]

I'm sorry, since when did it become such a noble cause to want to defy the spirit of the GPL, and then whine and gripe when it goes from spirit to legal fact? Again, you have to know the license of the software you're modifying before you go and do so, otherwise you're a damned fool.

Since people started realizing what a ridiculous nutjob RMS and his cult of followers are. GPL isn't about freedom as you can see by GPL v3, which was created for the shear purpose of preventing someone else from exercising a specific freedom with the software.

RMS and his followers are a bunch of ignorant hypocrites for the most part.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

GPL v3 was created for the purpose of preventing someone from stripping users of core software freedoms.
If you want redistributors of your software to be able to do that, feel free to choose a different license.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

GPL v3 was created for the purpose of stripping developers of core software freedoms.

Fixed that for you.

Re:AGPL: your rights to someone else's....

[Em Adespoton]

AGPL is GNU banditry of the ultimate order. If you don't buy software to use on your own computer, but simply run the services that they offer on their servers, this license would mean that you get to see, use and distribute their source code.

It's not "their" source code, it's the source code of whoever originally wrote the software and decided to release it under the AGPL. If the companies hosting the software don't like that, they're perfectly welcome to stop being freeloaders and write their own.

Added to this, we're talking about implemented algorithms here. Personally, if I'm going to host something using someone else's services, I'd like to know what those services are. I'm paying for the service, not some "secret sauce" knowledge. I'm the type of person that likes to know what I'm getting. Just like I expect to see a list of ingredients in order of most used to least used, plus a nutritional breakout, on the side of processed food I buy, I'd like to have a description of what goes in to the processed services I buy. Of course, I'd also like to know security and privacy policies for how the service handles my information, similar to how I like to know how the foods and people are treated that create the food I buy.

Some people may not care about all this, and are fine with black box consumerism. That's fine. But I'm not in that market segment, I'm in the other one. So I'll buy services from companies who use the AGPL or equivalent (including closed source where they give me access for review). Remember: once you move into SaaS, you can't really guarantee that what they let you look at is what they're running anyway; there has to be some level of trust.

Re:AGPL: your rights to someone else's....

[Microlith]

GPL isn't about freedom as you can see by GPL v3, which was created for the shear purpose of preventing someone else from exercising a specific freedom with the software.

What freedom would that be?

Re:AGPL: your rights to someone else's....

[zakkudo]

After reading posts like these, I can't help but wonder if the GCC folks have to deal with a swamp pile of bug reports written this way. The kind of writing that makes developers close up into a clamshell. If the GPL is that horrible to you, just don't use it. You as might as well go around yelling at vegetarians not eating meat, children for being dirty, or feminists standing up for their rights.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

Exploiting a loophole to keep users from exercising freedoms the software's actual author wanted them to have is a core freedom for devlopers?

Re:AGPL: your rights to someone else's....

[Microlith]

The GPL was not created for developers, it was made for the people after the developers.

Re:AGPL: your rights to someone else's....

[cheesybagel]

If you consider Tivoisation to be a freedom you need to get your head examined.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

Then it's useless because access to the so is of no use to anyone that isn't a developer.

Re:AGPL: your rights to someone else's....

[stenvar]

Banditry? How is it "banditry"? People offer you software under some license. It's your choice whether you use it or not.

Re:AGPL: your rights to someone else's....

[martin-boundary]

The world is changing, and the GPL must move with the times. Today, "the network is the computer" has never been more true. It is best to start thinking of PCs like cores in a single internet wide computer system. This paradigm is where high performance computing models in computer science are headed, at any rate.

If it makes sense that the GPL should apply regardless of the particular core a piece of GPL'd software runs on, then it makes sense that the GPL should apply regardless of the particular server a piece of GPL'd software runs on, too.

Re:AGPL: your rights to someone else's....

[martin-boundary]

No, it was made for *both* non-developers and developers.

The GPL allows free modification of the software, which is valuable to developers.

The GPL allows non-developers to engage (hire or convince) any developer of their choice to modify the software for them.

For example, take a game like SimCity, which has had all sorts of braindead problems. If this game had been released under the GPL instead, then any slashdotter who can program could have fixed a couple of the more glaring issues and made the game playable for lots of people. Alternatively, any gamer (non-programmer) who had a lot of experience with the gameplay and who figured out some improvements could post a message on a forum calling on programmers to make that *exact* change for him.

As it is, SimCity isn't GPL licensed, so anyone with a suggestion has to email EA with an idea, which may or may not be responded to, and may or may not fit with the plans EA has for monetizing the game.

Re:AGPL: your rights to someone else's....

[MikeBabcock]

Exactly -- understanding the purpose of the GPL requires nothing more than reading RMS' very old rant about printer drivers.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

If you don't buy software to use on your own computer, but simply run the services that they offer on their servers, this license would mean that you get to see, use and distribute their source code.

Well, it is GPL software and it is effectively being redistributed to 3rd parties.

Wrong! It is a *fact* that it is *not* redistributed to 3rd parties. You use the word "effectively" because you know you are wrong and just do not like it.

Re:AGPL: your rights to someone else's....

[exomondo]

The benefits of that are clear but unattainable without an effective business model.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

The freedom to control the system they've built, just like governments make laws that restrict your freedom, the difference in the software world is that you can choose not to buy into such a system if you disagree and people who prefer that system even with its restrictions are free to buy into it if they so choose.

Take Tivo for example, many people like it, even with its restrictions. Now assuming the tangible user benefits of an open version are superior to the tangible user benefits of a closed system would you not expect an open alternative to succeed? Remembering those benefits aren't just a result of open vs closed, but the indirect effect that has on the funding, business model, content partners, content licensing, etc. I believe the software/hardware level is the wrong place to address open vs closed, it needs to be addressed at the content level, i would imagine you could create a capable and open version of Tivo but the problem would be content.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

The freedom to control the system they've built

But they* didn't build the whole system themselves, they built it on top of someone else's GPLv3 code. What about said someone else's freedom to control what they built?

* not talking about Tivo (because they didn't use GPLv3 code, obviously) or anyone else in particular

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

But they* didn't build the whole system themselves, they built it on top of someone else's GPLv3 code. What about said someone else's freedom to control what they built?

That's ok, the bits they didn't build themselves *are* still available and *are* still in control of the original author. However the GPL is about intolerance of others' ideology, we see it clearly in RMS' "with me or against me" attitude, the "we can co-operate but only if we do it my way" is precisely what drives people away from the GPL (and we see that in TFA) because it limits co-operation and most software developers are not tied to a specific software ideology. What we see in TFA is GPL advocates lamenting the fact that the "my way or the highway" approach is not palatable to developers, that "theft" and "stealing" of source code is not a real thing much less something to worry about, that sharing source code is more about altruism and using it without restrictions is *much* more acceptable.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

Some people may not care about all this, and are fine with black box consumerism. That's fine. But I'm not in that market segment, I'm in the other one.

So you don't use a phone, drive a car, ride a bus, go on boats or airplanes, use internet banking or stock/currency trading? This is just an extremely short list of exactly the things you don't inspect the source code of but are a *lot* more relevant to your livelihood than the things you do look at.

Re:AGPL: your rights to someone else's....

[Em Adespoton]

Some people may not care about all this, and are fine with black box consumerism. That's fine. But I'm not in that market segment, I'm in the other one.

So you don't use a phone, drive a car, ride a bus, go on boats or airplanes, use internet banking or stock/currency trading? This is just an extremely short list of exactly the things you don't inspect the source code of but are a *lot* more relevant to your livelihood than the things you do look at.

I'm sure you didn't mean that to be a straw man, but the only items in your list that really apply are (smart)phone, internet banking, and online trading. We're talking about people entrusting others with their data. My car doesn't have GPS; my phone is not a smartphone (I've got a fully rootable tablet for that stuff). I actually have the advantage to know what's happening in my internet banking software, and I don't touch online trading (primarily because it's such a black box).

I'm talking about trusting your data to someone else's services; not "black box" as in "do I know how everything I use works, and can I build it myself in a pinch?" Really, a better comparison would be using a credit card, as that's essentially trusting your data to someone else's services --- all that usage data goes who-knows where (whether you're a consumer or a merchant).

So no, source code inspection isn't as much of an issue as source code for services inspection. You can have some level of trust for source code via certification -- but when you're not the one using the source code, you'd need certification for the implementation and operation as well, and because of the human factor, you're unlikely to get certification in either of these areas that is robus (at least in the next decade).

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

That's ok, the bits they didn't build themselves *are* still available and *are* still in control of the original author.

And if the original author decides (s)he wants that control to include forbidding Tivoisation, then by your(?) own argument there's absolutely nothing wrong with that.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

And if the original author decides (s)he wants that control to include forbidding Tivoisation, then by your(?) own argument there's absolutely nothing wrong with that.

Absolutely! The problem is GPL advocates don't want to admit that the GPL takes away freedom or then state that the freedom it does take away is immoral or the work of the devil or some such and that developers should exert control over the works of others that are built atop theirs. In your example the BSD license is more freedom-respecting (hence why it is called "permissive" whilst the GPL is "restrictive") as the original code remains free and open whilst developers of derivatives are free to do as they wish with their derivatives, the license isn't viral, unlike the GPL. This is why the GPL is more about forcing an ideology than a free exchange of ideas.

Re:AGPL: your rights to someone else's....

[Anonymous Coward]

I'm sure you didn't mean that to be a straw man

pointing out that you are indeed ok with blackbox consumerism is not a strawman at all, unless you want to constrain yourself to one specific area? it's ok if you want to do that though but your sweeping statement is clearly incorrect.

but the only items in your list that really apply are (smart)phone, internet banking, and online trading. We're talking about people entrusting others with their data. My car doesn't have GPS; my phone is not a smartphone (I've got a fully rootable tablet for that stuff).

so you are quite happy with blackbox consumerism when that blackbox is the ECU in your car? it's ok if you are, i'm just wondering to what level you become willfully ignorant in your consumerism. you entrust your data to the software in cell phone towers that you don't inspect, to the operating system of your phone, to isps, to routers, to banks, to ATMs, etc... and these are exactly examples of blackbox consumerism that you do indeed use, and that's ok. people like to think they are in control of every aspect of their data and claim they oppose blackbox consumerism but really they aren't. if it makes you feel better to inspect *some* aspects of data services that's great, whatever helps you sleep, but the *fact* is you use plenty of them that you don't inspect that can track your location, eavesdrop on you and control potentially dangerous elements of your travel.

Re:AGPL: your rights to someone else's....

[Em Adespoton]

I'm sure you didn't mean that to be a straw man

pointing out that you are indeed ok with blackbox consumerism is not a strawman at all, unless you want to constrain yourself to one specific area? it's ok if you want to do that though but your sweeping statement is clearly incorrect.

but the only items in your list that really apply are (smart)phone, internet banking, and online trading. We're talking about people entrusting others with their data. My car doesn't have GPS; my phone is not a smartphone (I've got a fully rootable tablet for that stuff).

so you are quite happy with blackbox consumerism when that blackbox is the ECU in your car? it's ok if you are, i'm just wondering to what level you become willfully ignorant in your consumerism. you entrust your data to the software in cell phone towers that you don't inspect, to the operating system of your phone, to isps, to routers, to banks, to ATMs, etc... and these are exactly examples of blackbox consumerism that you do indeed use, and that's ok. people like to think they are in control of every aspect of their data and claim they oppose blackbox consumerism but really they aren't. if it makes you feel better to inspect *some* aspects of data services that's great, whatever helps you sleep, but the *fact* is you use plenty of them that you don't inspect that can track your location, eavesdrop on you and control potentially dangerous elements of your travel.

I'm quite happy with blackbox consumerism when it's the ECU in my car or the trusses on the bridge I drive over -- those are industry regulated and have engineering structures in place. Hence, *I* might not know exactly what's going on inside, but I am fully aware of the rules and guidelines (and QA processes) being used to ensure proper behaviour. That's about the level to which I become willfully ignorant -- by knowing what I'm ignorant of and what I'm trusting to others to regulate for me.

I don't entrust my data to cellphone towers; they're pretty weak, are used for tracking and data gathering purposes. I pretty much assume that any time I call a cell phone (or land line for that matter) that anything I say is quite possibly being recorded, and behave appropriately (which isn't to say I don't use them, just that I do so with full understanding that I am broadcasting information, not having a personal conversation). This trend continues with your other examples. If I know what's going in to the black box, what's coming out, and am satisfied with the processes in place to validate the integrity of the box, I don't worry too much; the probability levels of something bad happening end up lower than those for me being struck by a car crossing the street.

However, my original (and my current) point is that this isn't the issue we're discussing -- when you host all your own stuff on someone else's service, the black box is no longer static. The black box is no longer in your possession. Without being able to analyse what's going on inside, you have no idea what it's really doing or who it's doing it for. You have no idea when things are being changed, or how that change process works. This is due to their being very few engineering processes for online services currently.

I like to know when I'm potentially being tracked and how; I like to know the weaknesses in my car's design so I can anticipate them. Likewise, I like to know similar information about services I use online. When this information is not available, I am unable to make intelligent decisions based upon what information IS provided. Hence my original posts.

There's a difference between willfuly ignorant consumerism and informed consumerism; I have no problems with the second. My point is that when you hit SaaS, there's an extra level of disassociation that people normally don't identify, instead putting it at the same level as the ECU in your car, the routing system for your phone/internet/etc. It's not.

Just wait until...

[Livius]

The next version will be NP-complete.

A long time FSF supporter disagrees with you

[SuperKendall]

I hate feeding worthless trolls, but here goes anyway:

As a GPL supporter, I must protest that your arrogance does not reflect the views of all of us.

You aren't forced to give away your source.

That's pretty much the whole point of the GPL. Source changes you make MUST be contributed back. Yes it's nice for the ecosystem but it's an onerous legal burden that you can easily get wrong if you forget something. Why have that kind of legal exposure if you don't have to? That's what companies are thinking when looking at both licenses. You are writing as if companies and even individual coders are operating in the legal climate of 20 years ago; we are not.

And? Don't enter a contract if you don't want to be bound by its terms.

AND that is the reason why so many are choosing BSD now. Because they don't.

Are you the sole arbiter of such things?

How is pointing out plain fact being an "arbiter" of anything? He is pointing out quite accurately how changing code in a BSD code base gives you more options than changing code in a GPL code base. If you claim otherwise you do not even understand the point of the GPL, never mind the exact legal conditions it adds.

On the contrary, the GPL guarantees freedom

I have been a member of the FSF for decades now. I fully support RMS in any discussion that arises. You are wrong. It does NOT guarantee freedom for people actually writing code. It binds them in specific ways.

Now those ways are practically helpful for future users, but in no sense is anyone getting "more freedom" from a license that is specifically restrictive. Even though future users technically gain some freedom to use code from people who contributed (which is what you really mean but obscure by trying to change the definition of freedom to your own), they give back any gains they had because (a) people who would have written code not being able to contribute to that project because of the license, and (b) they lose any freedom to make further changes without contributing back.

Oh good, you preserved this little lie.

That was the only part I really agree with. You can easily make money using open source software and contributing back. It just happens to be much easier to do so using code with BSD licenses (even when you are giving back in either case). As a consultant MOST companies (nearing 100%) will not let me use GPL code when writing for them, but they will let me use BSD without issue - even though I explicitly add in any consulting contract that any modifications I make must be contributed back to any open source code I modify. The companies don't care about library changes going back, I've not had one company care about that. What they ALL care about is the legal danger of having all code they have worked on having to be released because any component is GPL, or possibly just being sued because of any change made to a GPL module by some later low-level maintainer. THAT is the REALITY on the ground of where the GPL is today.

Typical trolling AC, leading on for a while and blow it with a personal attack.

I'm not posting AC, I'm posting with the weight of being a full-time software developer for decades who has worked with, and contributed code to open source code with all kinds of licenses for years.

Just to warn you I have no intention of reading anything further you write as I'm sure it will simply be more insults directed at me. I just wanted an impressionable younger generation to realize that your nonsense, arrogance and general ugliness does not reflect the views of all FSF and GPL supporters. Really you CAN support the GPL without some kind of maniacal world-view wherein restrictions are really freedom.

There is still a valid point to the GPL, it was especially useful many years ago top open up people to the idea of open source. But that works is done and we are in a new phase where to spread TRUE freedom the GPL has to sit back for a while and let the BSD soften up ground it cannot reach. At some point in the future it will be possible to layer back in more GPL use, but that time has not yet come.

Re:A long time FSF supporter disagrees with you

[Anonymous Coward]

That's pretty much the whole point of the GPL. Source changes you make MUST be contributed back. Yes it's nice for the ecosystem but it's an onerous legal burden that you can easily get wrong if you forget something. Why have that kind of legal exposure if you don't have to? That's what companies are thinking when looking at both licenses. You are writing as if companies and even individual coders are operating in the legal climate of 20 years ago; we are not.

I find it interesting how this argument shows up quite often, without actually being pursued to its logical conclusion. As it happens, that conclusion is a repeat of history - management decisions about 'trade secrets' will lead up to closed-source forks and dropping of funding for the original open source. It's an inevitable consequence of short-horizon thinking specific for current management culture and can be viewed as sort of a classic case of a game-theoretical problem. With many contributors, any single one will always benefit from keeping some/all of its interesting additions not contributed back, as it gives a competitive advantage. So all rational actors will prefer to do this, which leads to reaching a critical point of not enough development happening in the open, with eventually all involved companies maintaining private forks for a higher cost and worse efficiency. A typical case of a Nash equilibrium where everyone loses, due to the sharing equilibrium being unstable. This is in fact the main advantage of GPL, it eliminates the private branch option, forcing the sharing equilibrium to be stable. Of course, one can choose not to play the game, and incur the expense of doing all the work from zero in-house (which can or can not be more cost effective, depending on the particular circumstances).

As a consultant MOST companies (nearing 100%) will not let me use GPL code when writing for them, but they will let me use BSD without issue - even though I explicitly add in any consulting contract that any modifications I make must be contributed back to any open source code I modify. The companies don't care about library changes going back, I've not had one company care about that. What they ALL care about is the legal danger of having all code they have worked on having to be released because any component is GPL, or possibly just being sued because of any change made to a GPL module by some later low-level maintainer. THAT is the REALITY on the ground of where the GPL is today.

Indeed. And this is just ONE step removed from not contributing back at all for non-GPL code. Which makes it all the more difficult to keep the project alive. This is, after all, a competitive world, where one either survives or not. However, I would argue at this point that the true problem is not with GPL, but with the confusing legal framework for copyright, and with the still uneasy attitude of most companies (and their legal departments) about sharing code.

There is still a valid point to the GPL, it was especially useful many years ago top open up people to the idea of open source. But that works is done and we are in a new phase where to spread TRUE freedom the GPL has to sit back for a while and let the BSD soften up ground it cannot reach. At some point in the future it will be possible to layer back in more GPL use, but that time has not yet come.

I hope you're right and I'm just over-cynical, but I have *strong* doubts that today's culture of corporate greed has a lot of softening potential to be achieved via BSD rather than GPL. Hope for the best and plan for the worst is time-tested, unfortunately.

Nothing could be more wrong

[SuperKendall]

LLVM is one of their key tools in trying to leverage that. This is done for profit, mostly by taking money out of the pockets of people like Slashdotters. It is a tool in ensuring they will be able to build developer environments where they take your source code and hide it from you.

Nothing could be further from the truth. By basing XCode on LLWM, it makes it EASIER to write third-party tools that can properly work over the source true with the same rich understanding of context.

Prior to LLVM, when XCode was based more on GCC, XCode was the only thing that understood why it was parsing code the way it was for display and code completion. Now that any tool can have access to the same AST for the code that XCode is seeing, other software can act in ways that make sense for the code. More advanced re-factoring tools are now possible, thanks in large part to LLVM... Apple could have easily just built something like LLVM into XCode and left it totally proprietary.

Re:Nothing could be more wrong

[rtfa-troll]

Nothing could be further from the truth. By basing XCode on LLWM, it makes it EASIER to write third-party tools that can properly work over the source true with the same rich understanding of context.

Please don't get me wrong. I'm not questioning that LLVM is technically better in a number of ways, especially the ability to interoperate and especially in ways which are designed to encourage developers to get trapped using it.

What I'm wondering is, why concentrate on a project where the aim is to rewrite the entire compiler from zero when there was nothing in the GPL which would stop them from having using it to generate their entire proprietary code base. They could have forked GCC and provided an EGCS like clone which did what they wanted. The saving would have been huge.

The answer to that is simple. They would like to be able to push fully free operating systems like FreeBSD, Linux and OpenBSD out of the market. Their best way to do this is to get as much as possible of those systems BSD licensed so that they can build fully closed versions which move ahead of the rest of the system.

Re:Nothing could be more wrong

[SuperKendall]

The answer to that is simple.

Yes it is, but it is not the answer you gave. If Apple cared about pushing out BSD and Linux, wouldn't they put more than a token effort into OS X server? Apple doesn't need to push Linux of the desktop, because the desktop has become irrelevant.

No, the simple answer is that even if you could just use all the GCC code you liked any way you wanted, the way GCC is built does not lend itself to being part of other tools. As in, it's not so easy to just parse some arbitrary code and get a sense of where the tokens are at.

In reality the "huge savings" came about in writing a whole new compiler chain from scratch, which was easier overall than trying to get GCC parsing integrated into anything else!

The side benefit going forward is a WAY better compiler design that can integrate new ideas very quickly, and as I said be used as part of many different tools.

Re:Nothing could be more wrong

[Anonymous Coward]

What I'm wondering is, why concentrate on a project where the aim is to rewrite the entire compiler from zero when there was nothing in the GPL which would stop them from having using it to generate their entire proprietary code base. They could have forked GCC and provided an EGCS like clone which did what they wanted. The saving would have been huge.

There was nothing in GPLv2 which Apple had a problem with. What they don't like is GPLv3.

Could they have done EGCS2: Electric Boogaloo? Sure, but who the fuck are you to say that's the only acceptable course of action? There's nothing wrong with backing a different project instead. Nor is there anything wrong with the LLVM licensing choices, which (IIRC) actually predated Apple getting involved.

Of note: while license politics dictated that Apple couldn't stay with mainstream GCC, they were far from the only motivation for going with LLVM. GCC is notoriously a giant mess of legacy spaghetti C code. LLVM is a clean, modern, highly modular C++ design. It's much easier to add new target architectures and new optimization techniques, and much easier to avoid breaking existing code while doing so. And it's much easier to test the results, due to a huge commitment to integrated test features.

Back when egcs happened, one of the main reasons it was a fork rather than a new project was that there wasn't an alternative project waiting in the wings. This time, there was. And Apple already had a history with it, from having hired its author and used the early incomplete versions for purposes other than a complete compiler (think: shader compilers in graphics drivers). It's insane to fault them for going with what looked like a chance to do a clean break from gcc madness, especially given current hindsight (it's worked out rather well for them).

It's not just Apple which is enthusiastic about LLVM either. A ton of former GCC contributors have happily jumped on the train. Not only is it technically easier to write code for, they can actually get shit done and merged into an official release without having to deal with FSF zealotry and politics. The temporary egcs fork forced the FSF to have some humility for a while, but the arrogance and idiocy has definitely returned over time.

But maybe I shouldn't be trying to reason with you. This stuff you're saying:

LLVM is one of their key tools in trying to leverage that. This is done for profit, mostly by taking money out of the pockets of people like Slashdotters. It is a tool in ensuring they will be able to build developer environments where they take your source code and hide it from you.

It's crazy tinfoil hat paranoia. How is an open source compiler going to "take money out of the pockets of people like Slashdotters"? How can a development environment take your own fucking source code and hide it from you? Even if Apple turned around and took a branch of LLVM/clang 100% proprietary tomorrow, you'd still have any source code you wrote for it! They can't reach out and delete it from your computer. Nor could they stop others from forking the last open version. (Which would happen in about a millisecond. There's too many other enthusiastic users of LLVM now for it to die.)

But they aren't going to do that. It would be stupid. They benefit a lot from community involvement. They can make it a higher quality tool by keeping it open, and they aren't going to get a leg up on any competitors by closing it, therefore it will stay open. It's that simple.

The answer to that is simple. They would like to be able to push fully free operating systems like FreeBSD, Linux and OpenBSD out of the market. Their best way to do this is to get as much as possible of those systems BSD licensed so that they can build fully closed versions which move ahead of the rest of the system.

YEAH YEAH MAN, IT'S SOOOOOO TRUE. THEY'RE GETTING STUFF BSD LICENSED SO

Consider my points again.

[SuperKendall]

You are not a GPL supporter you are an astroturfing troll. Go away.

I have supported free software, and RMS specifically, on Slashdot for years.

If I am astroturfing, for who? And why would I do that for decades?

Instead I am exactly what I say - a long-time software developer, currently an iOS consultant but before that an IT developer for over a decade and also a computer science graduate, who has cared deeply about the programming industry as a whole for a long, long time.

I will not go away because other people need to know practical realities that all too many people on Slashdot want to ignore. I am here to help inform and guide those that people stuck in their ways would mislead.

I would insult you in return at this point but the topic is too profoundly important for insult.

Nobody is forcing you to benefit from my work. If you want to use my work in your product without obeying the GPL

Why are you overlooking the many points I made?

1) I don't want to benefit from your work without obeying the GPL. As I said in all my contracts I explicitly state that any code changes I make to open source libraries I am allowed to send those changes back in. In summary to be very clear, I WANT to send you back changes and obey the GPL. That is 100% not the problem in anything I've ever run across.

2) As I stated the real problem is that a company or client does not want the legal exposure - even if they INTEND to give you back all changes, mistakes happen and they may simply forget. Far more likely is that in five years, someone maintaining the code base will not realize they are in a GPL protected portion of code (because it is VERY easy to stop in a debugger and change a line of code without looking at the header) and then also they have made a change they were supposed to contribute back and now have not. So there is an endless source of potential liability that they simply do not have with BSD code, where the expectation is that code will be given back but nothing will happen if you don't or forget.

3) Some changes never make it back but they are not from people who would have used your GPL code anyway; in the meantime you DO get many changes back from people who also would not have used your GPL code but like to contribute changes.

4) Nobody is forcing me to use your work. But you are forcing me to take on legal responsibility if I choose to use your GPL'ed work, beyond the mere technical effort needed to integrate your code. In my own code for my own company I do not mind at all using GPL code but for many other companies that is simply a non-starter, so your code just does not get used. You need to think about it from your side; are you producing the code to help people or not? I BSD license my own code because the reason I share is only to help others, not for the drive to have others grow my project. I don't care if parts of my code get folded into other things, or enhanced beyond all recognition into a thing of beauty that I will never see. The important part is that I helped in some way to make that possible; to for a brief time stand against entropy and for progress.

Basically the problem is less with the GPL, and more with the legal climate in the U.S. especially (but really the whole world now) that is making the GPL less practical to use. Under such conditions the BSD works better as an explicit promise that you want other people to enjoy code and you have no intent or (much more importantly) CAUSE to sue someone who likes your code. It still communicates the desire that people send changes back; it just does not impose a non-technical and therefore unwelcome burden on the user. In fact it specifically relieves them of that unwelcome burden that is present in almost any other case!

Re:Consider my points again.

[Anonymous Coward]

As I stated the real problem is that a company or client does not want the legal exposure

The problem seems to be you and not the companies. I have worked on any number of contracts where GPL software was used and developed with no problem at all.

You see to think a GPL license somehow "infects" separately developed software. Since this is simply not true, and a quick check with company's legal department will prove it, it is probably your fud that is causing the companies a problem as much as anything. Like any license you need to legally verify there are no problems in the particular circumstances but once that's it's just a license like any other.

Re:Consider my points again.

[Anonymous Coward]

Despite any support you may have for the GPL, you clearly have a very poor understanding of its requirements as indicated by your statement that

someone maintaining the code base will not realize they are in a GPL protected portion of code (because it is VERY easy to stop in a debugger and change a line of code without looking at the header) and then also they have made a change they were supposed to contribute back and now have not.

There is not, and has never been, any requirement that using code under the GPL require and changes to be "contribute[d] back". The requirement is simply that when distributing the GPLed code that the source code also be distributed (or made available) to those receiving binaries. Since this requirement is the same whether or not changes are made to the code, there should be no concern about "not realizing" a change was made in GPL code. That GPL code needs to be distributed with the binary regardless of whether changes are made.

C++11: language and library?

[Aidtopia]

The standard specifies compiler behavior and the run-time library behavior. I know GCC has been pretty up to date with respect to the language features, but there are still some "Partial" and "No" entries in the run-time library implementation's C++11 status. Is Clang's library implementation complete with respect to the C++11 standard?

Re: BSd in a compiler

[glennrrr]

The advantage for Apple was that the GPL was making them choose between integrating not only the compiler but also the syntax parser into Xcode and virally making Xcode GPL as well or continue having a substandard experience of calling gcc as a command line tool. Xcode is much much better since ditching gcc as Apple now has the ability to modularize components and call methods directly. The code completion and static analysis are first rate, and they'd have gotten neither of those from gcc, not to mention taking full control over the direction of Objective-C with things like blocks, ARC and more types of literals.

Microsoft C++ 11 -- Not

[Anonymous Coward]

I'm not understanding how Microsoft's Visual Studio 2012 (formerly optimistically called C++ 11), can be such laggards in C++ 11. Many of the standard's features are missing. I don't understand how Microsoft can promote the rebirth of C++ and drop the ball. This is a great example of open source triumphing over closed source.

Re:Microsoft C++ 11 -- Not

[kthreadd]

The internal version number for Visual Studio 2012 is 11, just as the version number for Visual Studio 2010 is 10. It has no connection with C++ version support.

Library support

[Anonymous Coward]

C++11 support in GCC is not "more or less complete" by default, because of its dependency on the ridiculously slow-to-update libstdc++.

libc++ (default in clang, and usable by GCC if you're willing to put in a bit of effort), on the other hand, is feature-complete, I believe.