LLVM Clang Compiler Now C++11 Feature Complete 291
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."
Thank you, Apple! (Score:5, Insightful)
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! (Score:5, Insightful)
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 [gnu.org] 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.
Nothing could be more wrong (Score:5, Insightful)
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 (Score:4, Informative)
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: (Score:3)
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 eve
Re: (Score:3)
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 bec
Re: (Score:2)
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: (Score:3, Interesting)
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 cle
Re: (Score:3)
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: (Score:2)
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 t
Re: (Score:2)
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: (Score:3)
I've yet to see that 'fact' supported by anyone with proper understanding of the issues and no axe to grind.
Re: (Score:3)
Well, it is GPL software and it is effectively being redistributed to 3rd parties.
Oh good, we've devolved into petty name-calling already!
Re: (Score:2)
What freedom would that be?
Re: (Score:3)
The GPL was not created for developers, it was made for the people after the developers.
Re: (Score:2)
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 [wikipedia.org], 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 gam
Re: (Score:3)
Exactly -- understanding the purpose of the GPL requires nothing more than reading RMS' very old rant about printer drivers.
Re: (Score:2)
Banditry? How is it "banditry"? People offer you software under some license. It's your choice whether you use it or not.
Re: (Score:2)
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
Re:Thank you, Apple! (Score:5, Interesting)
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! (Score:4, Insightful)
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: (Score:2, Flamebait)
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: (Score:3, Informative)
Because the AC in the initial post in this thread did.
Re:Thank you, Apple! (Score:5, Insightful)
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: (Score:3, Insightful)
Re:Thank you, Apple! (Score:5, Informative)
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
BSD (Score:2, Insightful)
One of the great things about Clang and LLVM are they are BSD licensed rather than GPL.
Re: (Score:2, Insightful)
So are you seriously trying to start this flamewar again? Do you have nothing else to say?
Re: (Score:2)
Re: (Score:2, Insightful)
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 t
Re:BSD (Score:5, Insightful)
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: (Score:2)
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
Re: (Score:2)
We do, actually. The BSD TCP/IP stack isn't actually a part of windows.
None? Or do you mean, "acceptance by companies that are willing to take but unwilling to contribute"?
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
Neither option is always suitable for everybody..
Re: (Score:2)
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 lic
Re: (Score:2)
I hate feeding worthless trolls, but here goes anyway:
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.
And? Don't enter a contract if
A long time FSF supporter disagrees with you (Score:5, Interesting)
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.
Consider my points again. (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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 ups
Re:BSD (Score:5, Insightful)
What exactly is the advantage of a BSD license for a compiler?
Re: (Score:2)
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
Re: (Score:2)
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 (Score:5, Interesting)
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: (Score:2)
For most of us it doesn't matter at all.
Re: (Score:2)
Well they didn't exactly "switch" to Clang. They created Clang.
Re: (Score:2)
Maybe the IDE vendors should release their software under a compatible license. Profit!
OpenMp (Score:2)
Re: (Score:2)
More complete? (Score:3)
How can something be more Complete? I can understand less complete. Does this imply knowledge of the future?
Just wait until... (Score:3)
The next version will be NP-complete.
Re: (Score:2)
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: (Score:2)
P.S. Sheldon Cooper is that you?
Is there an in-print specification of C++11? (Score:2)
Re: (Score:2)
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.
C++11: language and library? (Score:2)
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 [gnu.org]. Is Clang's library implementation complete with respect to the C++11 standard?
Re:Linux (Score:5, Interesting)
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 (Score:3)
The phenomenon is not just restricted to IT companies. It's the borken part of human nature. Te Greeks calledit 'hubris'.
Re: (Score:2)
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,
Re: (Score:2)
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 w
Re: (Score:2)
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
Re: (Score:2)
I use "__thread" in gcc. Did that not work for you?
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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 A
Re: (Score:3)
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: (Score:3)
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 [wikipedia.org]
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: (Score:3)
Re: (Score:2)
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: (Score:2)
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 en
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Torvalds only cares about the kernel, and some diving app. A distribution can chose any userland it wants.
This Entire Thread (Score:2)
Re: (Score:2)
Ironically mirroring gcc itself....
Re: (Score:3)
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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 a
Re: (Score:2)
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: (Score:2)
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 (Score:5, Interesting)
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: (Score:2)
malloc does not call into the kernel.
Re:except for garbage collection (Score:4, Interesting)
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: (Score:3, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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 (Score:4, Interesting)
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 (Score:4, Informative)
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: (Score:3)
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 [gnu.org] 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." [gnu.org] You'd need -Wpedantic to get warnings about all GNU extensions and -pedantic-errors to get them as errors.