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!

[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!

[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: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: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: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.

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.