Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

LLVM Clang Compiler Now C++11 Feature Complete

timothy posted about a year and a half ago | from the ahead-of-the-curve dept.

Programming 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."

Sorry! There are no comments related to the filter you selected.

Thank you, Apple! (5, Insightful)

Anonymous Coward | about a year and a half ago | (#43503421)

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! (0)

Tough Love (215404) | about a year and a half ago | (#43503457)

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

Re:Thank you, Apple! (0)

BasilBrush (643681) | about a year and a half ago | (#43503563)

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! (4, Interesting)

_merlin (160982) | about a year and a half ago | (#43503619)

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! (3, Insightful)

ShanghaiBill (739463) | about a year and a half ago | (#43504261)

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! (0)

Anonymous Coward | about a year and a half ago | (#43503663)

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! (0)

Anonymous Coward | about a year and a half ago | (#43503675)

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! (0)

Anonymous Coward | about a year and a half ago | (#43503725)

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

Re:Thank you, Apple! (1)

TheRaven64 (641858) | about a year and a half ago | (#43503831)

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! (-1)

Anonymous Coward | about a year and a half ago | (#43503887)

The auto vectorization support is being developed mainly by Apple [uiuc.edu] .

Re:Thank you, Apple! (0)

Anonymous Coward | about a year and a half ago | (#43503979)

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! (0)

Anonymous Coward | about a year and a half ago | (#43504103)

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! (0)

Anonymous Coward | about a year and a half ago | (#43504213)

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

Re:Thank you, Apple! (1)

Em Adespoton (792954) | about a year and a half ago | (#43504221)

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! (5, Insightful)

rtfa-troll (1340807) | about a year and a half ago | (#43503707)

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.

Re:Thank you, Apple! (1, Informative)

Anonymous Coward | about a year and a half ago | (#43503843)

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

Re:Thank you, Apple! (3, Interesting)

rtfa-troll (1340807) | about a year and a half ago | (#43503927)

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! (2)

kthreadd (1558445) | about a year and a half ago | (#43504137)

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.

AGPL: your rights to someone else's.... (0)

unixisc (2429386) | about a year and a half ago | (#43503957)

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.... (-1)

Anonymous Coward | about a year and a half ago | (#43504007)

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.

Re:AGPL: your rights to someone else's.... (2)

Microlith (54737) | about a year and a half ago | (#43504081)

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.... (0, Troll)

BitZtream (692029) | about a year and a half ago | (#43504273)

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.

Sometimes I just don't get Slashdot mods... (1)

Anonymous Coward | about a year and a half ago | (#43503897)

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... (0)

Anonymous Coward | about a year and a half ago | (#43504183)

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.

Testing? (0)

Anonymous Coward | about a year and a half ago | (#43503429)

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

Linux (0)

Anonymous Coward | about a year and a half ago | (#43503445)

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 (4, Interesting)

_merlin (160982) | about a year and a half ago | (#43503547)

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 (0)

TheRealMindChild (743925) | about a year and a half ago | (#43503611)

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 (2)

DarkOx (621550) | about a year and a half ago | (#43503761)

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 (2)

gerddie (173963) | about a year and a half ago | (#43503791)

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:Linux (2)

interval1066 (668936) | about a year and a half ago | (#43503799)

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 (1)

BitZtream (692029) | about a year and a half ago | (#43504027)

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 (2)

Celarent Darii (1561999) | about a year and a half ago | (#43503613)

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

Re:Linux (0)

Moridineas (213502) | about a year and a half ago | (#43503699)

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 (0)

_merlin (160982) | about a year and a half ago | (#43503817)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503729)

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 (1)

unixisc (2429386) | about a year and a half ago | (#43503999)

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 (1)

kthreadd (1558445) | about a year and a half ago | (#43504219)

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

except for garbage collection (1)

Anonymous Coward | about a year and a half ago | (#43503459)

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 (1, Interesting)

TheRealMindChild (743925) | about a year and a half ago | (#43503745)

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 (3, Interesting)

sydneyfong (410107) | about a year and a half ago | (#43504267)

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 (2)

TheRaven64 (641858) | about a year and a half ago | (#43503865)

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 (1)

rtfa-troll (1340807) | about a year and a half ago | (#43503993)

"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 [iecc.com] 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 (1)

TheRaven64 (641858) | about a year and a half ago | (#43504231)

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 (5, Interesting)

VortexCortex (1117377) | about a year and a half ago | (#43504211)

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.

BSD (2, Insightful)

BasilBrush (643681) | about a year and a half ago | (#43503463)

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

Re:BSD (1, Insightful)

Microlith (54737) | about a year and a half ago | (#43503471)

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

Re:BSD (1, Insightful)

Anonymous Coward | about a year and a half ago | (#43503571)

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 (1)

thatkid_2002 (1529917) | about a year and a half ago | (#43503627)

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

Re:BSD (0)

Anonymous Coward | about a year and a half ago | (#43503941)

then you got older and developed a case of mental retardation

Re:BSD (0)

SuperKendall (25149) | about a year and a half ago | (#43504181)

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 (1, Insightful)

DarkOx (621550) | about a year and a half ago | (#43503885)

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 (5, Insightful)

SuperKendall (25149) | about a year and a half ago | (#43504243)

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 (1)

mark-t (151149) | about a year and a half ago | (#43503935)

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 (1)

Anonymous Coward | about a year and a half ago | (#43504017)

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 (1)

Microlith (54737) | about a year and a half ago | (#43504067)

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 (0)

Anonymous Coward | about a year and a half ago | (#43504237)

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 (1)

stinerman (812158) | about a year and a half ago | (#43503497)

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 (1)

Dr_Barnowl (709838) | about a year and a half ago | (#43503525)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503541)

The only plague on the compiler world are GCC extensions.

Re:BSD (0)

Anonymous Coward | about a year and a half ago | (#43503751)

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 (1)

TheRaven64 (641858) | about a year and a half ago | (#43503883)

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 (4, Insightful)

thatkid_2002 (1529917) | about a year and a half ago | (#43503545)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503695)

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

Re:BSD (0)

Anonymous Coward | about a year and a half ago | (#43503759)

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

Re:BSD (0)

Anonymous Coward | about a year and a half ago | (#43503829)

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

Re:BSD (0)

Anonymous Coward | about a year and a half ago | (#43503793)

Attaching the compiler libraries to a closed source IDE.

Re:BSD (1)

kthreadd (1558445) | about a year and a half ago | (#43503933)

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

Re:BSD (2)

larry bagina (561269) | about a year and a half ago | (#43503867)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503947)

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 (5, Interesting)

pavon (30274) | about a year and a half ago | (#43503917)

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 (0)

Anonymous Coward | about a year and a half ago | (#43504073)

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 (1)

phantomfive (622387) | about a year and a half ago | (#43504083)

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.

It's time to move on from GCC. (1)

Anonymous Coward | about a year and a half ago | (#43503489)

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.

This Entire Thread (1)

interval1066 (668936) | about a year and a half ago | (#43503723)

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

Re:This Entire Thread (0)

Anonymous Coward | about a year and a half ago | (#43503811)

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

Re:This Entire Thread (1)

mevets (322601) | about a year and a half ago | (#43503847)

Ironically mirroring gcc itself....

OpenMp (1)

darkHanzz (2579493) | about a year and a half ago | (#43503495)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503513)

OpenMP is unsuitable for number crunching.

Re:OpenMp (0)

Anonymous Coward | about a year and a half ago | (#43503603)

OpenMP is unsuitable for number crunching.

[citation required]

Re:OpenMp (0)

Anonymous Coward | about a year and a half ago | (#43503633)

here [khronos.org]

Re:OpenMp (0)

Anonymous Coward | about a year and a half ago | (#43503637)

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

Re:OpenMp (1)

TheRaven64 (641858) | about a year and a half ago | (#43503907)

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? (2)

goombah99 (560566) | about a year and a half ago | (#43503511)

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

Re:More complete? (0)

Anonymous Coward | about a year and a half ago | (#43503567)

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

Re:More complete? (0)

Anonymous Coward | about a year and a half ago | (#43503849)

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? (0)

Anonymous Coward | about a year and a half ago | (#43504195)

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

Just wait until... (2)

Livius (318358) | about a year and a half ago | (#43504203)

The next version will be NP-complete.

Re:More complete? (1)

AmiMoJo (196126) | about a year and a half ago | (#43504217)

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? (1)

AmiMoJo (196126) | about a year and a half ago | (#43504233)

P.S. Sheldon Cooper is that you?

Executable performance (1)

Excelcia (906188) | about a year and a half ago | (#43503579)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503589)

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

Re:Executable performance (1)

KiloByte (825081) | about a year and a half ago | (#43503899)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503977)

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 (0)

Anonymous Coward | about a year and a half ago | (#43503649)

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

Re:Executable performance (4, Interesting)

Excelcia (906188) | about a year and a half ago | (#43504029)

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 (1)

Anonymous Coward | about a year and a half ago | (#43504075)

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 (0)

iggymanz (596061) | about a year and a half ago | (#43504109)

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

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

mark-t (151149) | about a year and a half ago | (#43503871)

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? (0)

Anonymous Coward | about a year and a half ago | (#43504205)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?