LLVM Clang Compiler Now C++11 Feature Complete

Thank you, Apple! by Anonymous Coward · 2013-04-20 02:28 · 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! by _merlin · 2013-04-20 02:59 · Score: 4, 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! by rtfa-troll · 2013-04-20 03:13 · 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 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.

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Re:Thank you, Apple! by TheRaven64 · 2013-04-20 03:31 · Score: 1

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

--
I am TheRaven on Soylent News
Re:Thank you, Apple! by Anonymous Coward · 2013-04-20 03:34 · Score: 1, Informative

It has long been accepted fact that GPL does hurt open source in the long run.
Re:Thank you, Apple! by rtfa-troll · 2013-04-20 03:47 · 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 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.

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Re:Thank you, Apple! by kthreadd · 2013-04-20 04:19 · Score: 2

There may be a fair number of people who agree with this position, but it's never come close to being "accepted". In fact, anyone who knows the history of computing knows that originally most software was distributed under completely free licenses. That world was completely destroyed by proprietary software in the '70s and '80s and it was only the arrival of the GPL and GCC in particular which allowed, for example, the BSD operating systems to become self hosting and self sustaining.
Very true, BSD has a lot to thank GCC and the GNU project for. And not just BSD. It doesn't really matter which UNIX flavor you install today, most of them include or optionally provide the GNU userland.

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

If you release your software under the BSD license you can never put it back under the AGPL. The opposite is never true. If there turns out to be a true benefit later, you can always opt to change over. The answer is simple. They want something from you. Make sure you get something in return before you give it out. Money maybe; better benefit for your and your children's future.
I'm not an expert on either of those licenses, but do you really mean that you can't change BSD to AGPL? In that case that's news to me.
Re:Thank you, Apple! by Em+Adespoton · 2013-04-20 04:36 · Score: 1

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! by ShanghaiBill · 2013-04-20 04:43 · Score: 3, 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:Thank you, Apple! by SuperKendall · 2013-04-20 05:18 · Score: 2

Apply only contributes because then they don't have to spend effort every time they want to merge their private fork with the upstream.
Go to WWDC and talk with the actual developers working on it. That's not the case at all.
It *IS* true that Apple gains from less merging work by contributing code. But be realistic; there are real coders working on these things at Apple and just like ANY coder, they are happier the more people get to use their work. Developers that work at Apple are not mustache-twilrling villains; they are coders like you or I, just as motivated by people in the compiler community appreciating effort as they are by an Apple paycheck.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Re:Thank you, Apple! by BasilBrush · 2013-04-20 05:19 · Score: 1

Of course there's no private fork on the web, then it wouldn't be very private.
If it were so private they weren't distributing the binary, they wouldn't have to distribute the source with GPL either.
And there's no secret to what clang they are distributing:
clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
Re:Thank you, Apple! by BasilBrush · 2013-04-20 05:25 · Score: 1

If the LLVM/Clang developers had have more forethought and picked GPL they could have forced Apple though court to release those changes.
Clang was created by Apple. Why would they want to take themselves to court?
Re:Thank you, Apple! by BasilBrush · 2013-04-20 05:39 · Score: 1, 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:Thank you, Apple! by Microlith · 2013-04-20 06:03 · Score: 2, Informative

Because the AC in the initial post in this thread did.
Re:Thank you, Apple! by UnknowingFool · 2013-04-20 07:06 · Score: 2

Apple, and to a large extent Google, have come with new business models where they take the output of that process and rebundle it in a way which allows them to avoid sharing the key features which differentiate their products.
Um what? Clang is open source. WebKit was open sourced by Apple. Under the GPL they are only obligated to release modifications to the original KHTML base code. They are under no obiligations to release JavascriptCore or WebCore but they did. Apple didn't have to hire Michael Sweet and have him keep developing cups.

In Apple's case by adding proprietary GUIs and other features which mean that nobody else can the free stuff and compete with them.
It means you can't use their stuff which they want to keep proprietary. But you are free to compete to develop your own. Also under the BSD license which OS X is derived, Apple doesn't even have to release Darwin but they do.

LLVM is one of their key tools in trying to leverage that. This is done for profit, mostly by taking money out of the pockets of people like Slashdotters. It is a tool in ensuring they will be able to build developer environments where they take your source code and hide it from you.
Again, what? Clang is open source and Apple is a major contributor. LLVM is open source and Apple is a major contributor. LLVM was released under a BSD style license long before Apple was a contributor.

It is not a coincidence that we keep getting stories about there being lots of non-GPL software coming out etc. The shills want us to give them everything we have for free and have no need to return to the community.
Again, what? Do you even look at this page?

Correct answer: License under the AGPLv3 whenever you can and only back off to the GPL or LGPL, let alone MIT licenses when someone gives you a really compelling benefit for doing so.
And who are you to dictate to the authors what license they pick? LLVM picked a BSD license long before Apple was involved. NeXT used the same type of license long before Apple purchased them. Apple cannot change the license differently than the authors intended.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Thank you, Apple! by cheesybagel · 2013-04-20 07:11 · Score: 1

Apple supports OpenCL compilation using clang. I never saw any mention of this being open sourced. It seems all clang support for OpenCL has been developed somewhere else.
Re:Thank you, Apple! by cheesybagel · 2013-04-20 07:11 · Score: 1

GPL sure. But had they picked LGPL it would probably have been accepted as well since most of the interest is in the hooks it provides for IDEs.
Re:Thank you, Apple! by cheesybagel · 2013-04-20 07:21 · Score: 1

Clang is based on LLVM which was developed in an academic environment. WebKit is based on KHTML. Sure Apple could close source their code further but then they would have to keep updating their branch to match the open fork. That takes a non-insignificant amount of time and effort.
Over time people will realize why a compiler shouldn't be BSD licensed. There is a reason why other BSD licensed compilers died on the vine. Every hardware vendor will want a closed fork for their own architecture which never gets updated properly. This is less evident today when most of the world is only running x86 or ARM, which is licensed rather than manufactured by ARM Holdings, but in the embedded world it will be pretty much obvious.
Re:Thank you, Apple! by jonwil · 2013-04-20 07:33 · Score: 4, 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:Thank you, Apple! by UnknowingFool · 2013-04-20 07:38 · Score: 2

WebKit is based on KHTML. Sure Apple could close source their code further but then they would have to keep updating their branch to match the open fork. That takes a non-insignificant amount of time and effort.
WebKit consists of KHTML code plus Apple's changes and Apple's other code. Prior to 2005, Apple did not release the proprietary parts as they did not have to. Apple did not have to release it as open source but they did anyway. They don't have to match anyone's open fork of their code if they kept it closed.

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

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

This is less evident today when most of the world is only running x86 or ARM, which is licensed rather than manufactured by ARM Holdings, but in the embedded world it will be pretty much obvious.
So what you are saying is that it theoretically might be a problem but it isn't today?

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Thank you, Apple! by zakkudo · 2013-04-20 08:01 · Score: 1

Yes. This is exactly why Apple picked up CUPS. There was no possiblity of Apple doing something similar with LLVM/Clang. None at all.
Re:Thank you, Apple! by PhamNguyen · 2013-04-20 08:16 · Score: 5, Informative

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

True as well, and important too that we don't forget. When we put aside our differences we find that we're all really into it for the same thing.
Re:Thank you, Apple! by stenvar · 2013-04-20 09:11 · Score: 1

I don't see what you're complaining about. I've developed software under MIT licenses and got paid for it. Apple or someone pays LLVM developers as well. I don't like the proprietary products Apple is creating with open source software, but the solution to that is just not to buy their products and tell others not to buy their products.
Re:Thank you, Apple! by Pseudonym+Authority · 2013-04-20 09:49 · Score: 2, Insightful

GCC code based is a fucked-up, convoluted mess and is designed that way, due in no small part to RMS's fear that some evil proprietary coders might steal `his' code away from him. I pity the poor bastard who has to fork it.
Re:Thank you, Apple! by martin-boundary · 2013-04-20 13:04 · Score: 1

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

You can give out your virginity once only. If you licence under BSD, anyone can take your code and run with it. If you later relicence to GPL, companies can still use the earlier BSD licensed code instead of following the GPL rules.
1) If you license BSD, companies can use the code, and if they sprinkle their own code on top and distribute the software, nobody can take their modified code and freely sprinkle another set of changes on that.
2) If you license GPL, companies can use the code, and if they sprinkle their own code on top and distribute the software, anyone else can freely sprinkle new changes on that.
Re:Thank you, Apple! by MikeBabcock · 2013-04-20 14:10 · Score: 2

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

--
- Michael T. Babcock (Yes, I blog)
Re:Thank you, Apple! by cheesybagel · 2013-04-20 14:52 · Score: 1

It is a problem today. NVIDIA, Apple, AMD, Intel are shipping closed source CUDA and OpenCL compilers based on LLVM which basically do the same thing for different architectures. But sure keep dreaming in BSD fantasy land.
Re:Thank you, Apple! by cheesybagel · 2013-04-20 15:05 · Score: 1

Xcode is an IDE. If you do not know the difference between an IDE and a compiler you need to get yourself educated. Xcode uses clang or gcc to actually compile code AFAIK.
That 'opencl' stuff does not include full support for actually compiling working opencl code in the general sense. Otherwise there wouldn't be people in academia replicating what closed source llvm users such as NVIDIA, AMD, Intel, Apple are distributing out there. Nor would I need to use nvcc to compile my OpenCL code as I do now.
Re:Thank you, Apple! by cheesybagel · 2013-04-20 15:08 · Score: 1

http://stackoverflow.com/questions/3580222/is-apples-opencl-implementation-using-clang-and-llvm-open-source
So no Apple's OpenCL compiler is not open source.
Re:Thank you, Apple! by UnknowingFool · 2013-04-20 16:18 · Score: 1

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

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Thank you, Apple! by kthreadd · 2013-04-20 16:45 · Score: 1

My history is a bit vague here but quickly reading the Wikipedia page suggests that Clang did originate at Apple. The LLVM project as a whole did not however.
Re:Thank you, Apple! by tlhIngan · 2013-04-20 17:35 · Score: 1

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

And depending on how close new versions stick to the old versions. Eventually the effort of maintaining the old branch is going to get bigger and bigger as the code base diverges.
Anyhow, why does everyone see BSD as bad because it allows closed source development? BSD is bad because it enables copyleft theft as well!
Yes, the GPL allows locking up BSD code as well. A GPL'd project can take code from a BSD project. However, a BSD project cannot take code from a GPL project.
This leads to scenarios that have played out before in the FOSS world - a GPL project takes code from a BSD project. But said BSD project cannot take back the improvements the GPL project made.
In fact, this scenario is even worse than closed source - at least closed source make it don't ask don't tell - the BSD project doesn't care. But the GPL'd project doing the same is flaunting the changed code in their face and they can't do a thing about it. Even worse, the GPL folks are arguing about BSD being locked up by proprietary licenses, when they're just as guilty of doing the same thing - the GPL is locking up BSD code.
Which is fine, if it wasn't for the GPL folks being so in-you-face about it and ignoring the ugly fact that they're just as guilty of the same thing. And claiming superiority about being better than BSD.
Anyhow, I would release my code GPLv2. Make it incompatible with a growing number of GPLv3(+) code out there. Interestingly, GPL can vulture its own as well - a v2 project using some v2+ code can find that v2+ code locked up if the code suddenly incorporates v3(+) code that turns the entire thing GPLv3. The mind boggles.
No wonder I've seen companies start enforcing open-source usage policies - it's much to easy to end up in a conflict where some v2 code and v3 code end up together inadvertently.
Re:Thank you, Apple! by rtfa-troll · 2013-04-20 18:55 · Score: 1
Which interests?
I am talking about several fundamental interests you have in your code
- as a user, in return for having handed out your code you would like to be able to use other people's code
- as a developer you would like your code to grow and become more valuable so it can be used for more
- the right to get paid for proprietary use of your code.
If someone wants to make a proprietary version from your code, you can then discuss with them. They can pay you if they think it's worth it. If you put it under the AGPLv3 this is pretty easy and clear. If you put it under the BSD license then they just take and that's it.
--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Re:Thank you, Apple! by kthreadd · 2013-04-20 20:00 · Score: 1

I guess it's a matter of personal optinion. Persionally I don't mind that someone can use open source code that I wrote and use it in a proprietary version. I don't see that as a problem. If they would pay me I would much prefer that they pay me for writing the source code or modify it for their needs, rhather than maintaining some dual licensing thing.
Re:Thank you, Apple! by rtfa-troll · 2013-04-20 22:01 · Score: 1

I guess it's a matter of personal optinion.

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

Personally I don't mind that someone can use open source code that I wrote and use it in a proprietary version. I don't see that as a problem. If they would pay me I would much prefer that they pay me for writing the source code or modify it for their needs, rather than maintaining some dual licensing thing.
I would say that, in most (though not all) cases, the AGPLv3 actually encourages this model. You add little improvements for each customer; the customers tend to be happy to share back because they know their competitors can't take the code and use it against them without also making it available back to them when they distribute. Your code gradually improves and becomes more useful. More people use it and so more people see special needs where they would like something developed for them.
It's very important to remember that the GPL licenses are designed with the interests of users in mind. The BSD licenses are designed with the interests of other developers in mind. You, yourself, have full right on your own code no matter what license you have put it out in already. This normally means that your own interests are more closely aligned with your users ("customers") than with other developers ("competitors"). The exception comes when other developers are working together on a project with you and contributing back in which case they become "partners". In most cases AGPLv3 is the best way to encourage that.

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Re:Thank you, Apple! by ilguido · 2013-04-21 00:23 · Score: 1

Um what? Clang is open source. WebKit was open sourced by Apple. Under the GPL they are only obligated to release modifications to the original KHTML base code. They are under no obiligations to release JavascriptCore or WebCore but they did.
They actually are: JavascriptCore and WebCore are both under the LGPL and KHTML derived.
Re:Thank you, Apple! by kthreadd · 2013-04-21 01:58 · Score: 1

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

A witch!!?!

--
Defining Statistics and Social Research
Re:Thank you, Apple! by angel'o'sphere · 2013-04-22 04:48 · Score: 1

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

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:Thank you, Apple! by cheesybagel · 2013-04-24 15:20 · Score: 1

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

except for garbage collection by Anonymous Coward · 2013-04-20 02:38 · Score: 1

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 by TheRealMindChild · 2013-04-20 03:18 · Score: 1, Interesting

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.

--

"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Re:except for garbage collection by TheRaven64 · 2013-04-20 03:37 · Score: 2

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.

--
I am TheRaven on Soylent News
Re:except for garbage collection by rtfa-troll · 2013-04-20 03:57 · Score: 1

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

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Re:except for garbage collection by VortexCortex · 2013-04-20 04:33 · 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:except for garbage collection by TheRaven64 · 2013-04-20 04:38 · Score: 1

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.

--
I am TheRaven on Soylent News
Re:except for garbage collection by sydneyfong · 2013-04-20 04:44 · Score: 3, 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).

--
Don't quote me on this.
Re:except for garbage collection by SpinyNorman · 2013-04-20 05:09 · Score: 1

I don't have a problem with the standard allowing for garbage collection, but I'm curious what types of real-world use cases make GC for C++ more convenient that explicit storage management?
The combination of STL and destructors-free-memory (on the frew occasions you need non-STL datastructures) seems convenient enough to me.
Re:except for garbage collection by paavo512 · 2013-04-20 06:39 · 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 by Anonymous Coward · 2013-04-20 06:53 · 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:except for garbage collection by paavo512 · 2013-04-20 07:40 · Score: 1

Calling into the kernel code every allocation / deallocation of dynamic memory is slow.
Yes it is, and no sane memory allocator is doing that, they all allocate memory from the OS in large chunks and then distribute it in-process as fast as they can. You are attacking a strawman. Anyway, this has nothing to do with GC, GC needs to allocate and deallocate memory as well.
Re:except for garbage collection by SpinyNorman · 2013-04-20 10:23 · Score: 1

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 by spitzak · 2013-04-20 11:45 · Score: 1

malloc does not call into the kernel.
Re:except for garbage collection by smellotron · 2013-04-20 18:02 · Score: 1
Calling into the kernel code every allocation / deallocation of dynamic memory is slow.

If you haven't already, I encourage you to download the glib source code and trawl around. Pick the latest code, or whatever you interact with on a daily basis. Check out the malloc code, it's not as daunting as it sounds. You should discover a few things:
- If your malloc size is big enough to trigger a mmap (128KB IIRC), then you are absolutely correct that the runtime library will invoke the OS on every allocation/deallocation. Until you hit your number-of-maps limit, at least. So yeah, repeated allocation and deallocation of large blocks of memory is bad in this implementation. But don't throw out the baby with the bathwater! mallopt can be used to tune the allocator to your program's expected behavior. As in: short-lived block sizes should probably be below the mmap threshold.
- If you don't trigger the mmap size threshold, then the allocator only goes to the OS if it needs to increase the size of the heap. Again, this behavior is tunable: how much to pull from the OS at once, and how much overhead to allow before returning space back to the OS.
If you're not writing software with high performance requirements, you can probably ignore all of this, because your program's bottlenecks are probably somewhere silly (and nobody cares, anyhow). If you are, this level of control is probably desirable whether you're using GC or deterministic deallocation.
Re:except for garbage collection by smellotron · 2013-04-20 18:19 · Score: 1

My copy of malloc calls sbrk and mmap/mremap/munmap—all kernel functions. How does yours get more virtual address space?
Re:except for garbage collection by UnknownSoldier · 2013-04-20 18:33 · Score: 1

> EA (the game company) created their own STL replacement basically just to add a GC and hashmaps, because they were tired of reimplementing these features IN EVERY DAMN GAME
No the _real_ reason was because STL was horribly designed and implemented in places:

However, some aspects of it make it hard to use and other aspects prevent it from performing as well as it could. Among game developers the most fundamental weakness is the std allocator design, and it is this weakness that was the largest contributing factor to the creation of EASTL. Secondarily was the lack of std STL containers designed to be memory-friendly. There are additional reasons that will be discussed below.
:
The following is a listing of some of the reasons why std STL and its current implementations are not currently ideal for game development. There are additional reasons, but the list here should hopefully convey to you some sense of the situation. Each of the items listed below deserves a document of its own, as a single sentence alone cannot fully convey the nature or significance of these items. Some of the items refer to the STL design, whereas some of the items refer to existing STL implementations. It would be best if these were discussed independently, but to many users this distinction is often of little practical significance because they have little choice but to use the standard library that comes with their compiler.
* std STL allocators are painful to work with and lead to code bloat and sub-optimal performance. This topic is addressed separately within this document.
* Useful STL extensions (e.g. slist, hash_map, shared_ptr) found in some std STL implementations are not portable because they don't exist in other versions of STL or are inconsistent between STL versions (though they are present in the current C++09 draft).
* The STL lacks functionality that game programmers find useful (e.g. intrusive containers) and which could be best optimized in a portable STL environment. See Appendix item 16.
* Existing std STL implementations use deep function calls. This results in low performance with compilers that are weak at inlining, as is the currently prevalent open-source C++ compiler. See Appendix item 15 and Appendix item 10.
* Existing STL implementations are hard to debug. For example, you typically cannot browse the contents of a std::list container with a debugger due to std::list's usage of void pointers. On the other hand, EASTL allows you to view lists without incurring a performance or memory cost. See Appendix item 2.
* The STL doesn't explicitly support alignment requirements of contained objects, yet non-default alignment requirements are common in game development. A std STL allocator has no way of knowing the alignment requirements of the objects it is being asked to allocate, aside from compiler extensions. Granted, this is part of the larger problem of the C++ language providing minimal support for alignment requirements. Alignment support is proposed for C++09.
* STL containers won't let you insert an entry into a container without supplying an entry to copy from. This can be inefficient in the case of elements that are expensive to construct.
* The STL implementations that are provided by compiler vendors for the most popular PC and console (box connected to TV) gaming platforms have performance problems. EASTL generally outperforms all existing STL implementations; it does so partly due to algorithmic improvements but mostly due to practical improvements that take into account compiler and hardware behavior. See Appendix item 20.
* Existing STL implementations are hard to debug/trace, as some STL implementations use cryptic variable names and unusual data structures and have no code documentation. See Appendix item 2.
* STL containers have private implementations that don't allow you to work with their data structures in a portable way, yet sometimes this is an important thing to be able to do (e.g. node pools). See A
Re:except for garbage collection by TheRaven64 · 2013-04-20 21:00 · Score: 1

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

--
I am TheRaven on Soylent News
Re:except for garbage collection by gbjbaanb · 2013-04-21 02:15 · Score: 1

GC also has to pause your program (even for a short time) and then copy memory blocks around to compact the heap (or it will rapidly run out). Memory copying is a slow operation, and the additional time spent calculating which blocks to move is also adding extra time that non-GC systems don't incur.
Then there's the GC killer - locality of data, in most non-GC apps memory is allocated contiguously so it can be read from relatively slow RAM into CPU cache in a straight hit, in GC systems the memory blocks can more often be located all over the heap, and each one is referenced via an intermediate GC pointer, which means you need many hits to read the same data - with today's super-fast CPUs requiring data to be present in the caches, this can murder performance on a GC system.
Saying GC is a basic feature just means the OP has bought into the hype without giving it much critical review.
Re:except for garbage collection by spitzak · 2013-04-21 11:11 · Score: 1

It does not call the kernel on every malloc call, that's what I meant. The op acted as though malloc/new called the kernel every time.
Re:except for garbage collection by spitzak · 2013-04-21 12:56 · Score: 1

The op said "Calling into the kernel code every allocation / deallocation of dynamic memory is slow." I'm pretty certain no malloc has done that for decades.
Re:except for garbage collection by smellotron · 2013-04-21 14:37 · Score: 1

that's what I meant

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

BSD by BasilBrush · 2013-04-20 02:38 · Score: 2, Insightful

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

Re:BSD by Microlith · 2013-04-20 02:40 · Score: 1, Insightful

So are you seriously trying to start this flamewar again? Do you have nothing else to say?
Re:BSD by stinerman · 2013-04-20 02:44 · Score: 1

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 by Dr_Barnowl · 2013-04-20 02:48 · Score: 1

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 by thatkid_2002 · 2013-04-20 02:50 · Score: 4, Insightful

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 by Anonymous Coward · 2013-04-20 02:53 · Score: 1, Insightful

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 by thatkid_2002 · 2013-04-20 02:59 · Score: 1

Ah I remember when I was young and things were this simple.
Re:BSD by larry+bagina · 2013-04-20 03:38 · 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 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.

--
Do you even lift?
These aren't the 'roids you're looking for.
Re:BSD by TheRaven64 · 2013-04-20 03:41 · Score: 1

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.

--
I am TheRaven on Soylent News
Re:BSD by DarkOx · 2013-04-20 03:41 · Score: 1, 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 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.

--
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Re:BSD by pavon · 2013-04-20 03:45 · 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:BSD by kthreadd · 2013-04-20 03:48 · Score: 1

Maybe the IDE vendors should release their software under a compatible license. Profit!
Re:BSD by mark-t · 2013-04-20 03:48 · Score: 1

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.

--
File under 'M' for 'Manic ranting'
Re:BSD by Anonymous Coward · 2013-04-20 04:00 · Score: 1

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 by Microlith · 2013-04-20 04:09 · Score: 1

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 by phantomfive · 2013-04-20 04:14 · Score: 1

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.

--
"First they came for the slanderers and i said nothing."
Re:BSD by SuperKendall · 2013-04-20 04:39 · 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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Re:BSD by BitZtream · 2013-04-20 04:55 · Score: 1

The only freedom this limits in practice use is the freedom to profit off the work of others. I am not a supported of IP as a concept in general but it exists; to that end GPL has succeeded in ensuring there is a workable free ecosystem that I really don't think would exist with out it.
How incredibly shorts sighted and ignorant of you.
If the say ... the standard IP implementation that ... EVERYONE ON THE FUCKING PLANET users was GPL'd instead of BSD'd ... then we would have unique IP networking implementations across every OS on the planet, assuming that the Internet would exist yet in the first place since Cisco isn't going to jump on your GPL'd protocol since they can't do nearly as much neat tricks to make them a viable company.
Its sad that you don't realize what a chilling effect GPL has on software acceptance.
You fail to understand that shared standards are what makes computing work. I'm sure you'll scream OPEN STANDARD and then that actually means GPL style standards. So instead of being open and working with others, you want everyone else to play the same way you do. If they don't, you take your toys and go home.
Spoiled brats, the entire lot of you.

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Re:BSD by BitZtream · 2013-04-20 05:01 · Score: 1

BSD in no way takes options away downstream.
Everyone will have access to the BSD code.
You may not get access to some new code that was combined with it ... but that code was never BSD code ... you never had access to it ... nothing was 'taken away from you' because you didn't have it in the first place.
GPL doesn't 'keep people from taking things away from you' it forces them to give it to you.
If you think GPL is about freedom, why is it such a long list of restrictions compared to AT WORST, the 4 a BSD license carries (now days everyone uses only 2). I can handwrite the BSD license in a minute or so ... I think my printer would run out of ink if I tried to print a copy of the GPL in standard font right now.
It really is mind boggling how you can talk about freedom which is so obviously not.

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Re:BSD by Microlith · 2013-04-20 05:11 · Score: 1

we would have unique IP networking implementations across every OS on the planet
We do, actually. The BSD TCP/IP stack isn't actually a part of windows.

Its sad that you don't realize what a chilling effect GPL has on software acceptance.
None? Or do you mean, "acceptance by companies that are willing to take but unwilling to contribute"?

Spoiled brats, the entire lot of you.
Care to come back when you're capable of coming up with an actual point rather than a spittle-flecked rant with little substance?
Re:BSD by BasilBrush · 2013-04-20 05:43 · Score: 1

Well they didn't exactly "switch" to Clang. They created Clang.
Re:BSD by K.+S.+Kyosuke · 2013-04-20 05:53 · Score: 1

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?

--
Ezekiel 23:20
Re:BSD by AaronW · 2013-04-20 06:22 · Score: 1

I work for a MIPS vendor (Cavium) and I know we push almost all of our extensions upstream and we ship very recent versions to customers. We're currently shipping 4.7 to customers. This includes support for the Cavium OCTEON proprietary assembly instructions as well (encryption, hashing, load/store indexed and atomic instructions). There is a lot of active GCC development where I work and in fact we are looking for more GCC developers for both MIPS and ARM.
Similarly we work hard to push all of our stuff upstream to the mainline Linux kernel.
I need to work on pushing up our U-Boot bootloader support after I migrate to GIT though that's going to be a huge project since we have more code for our SOC than any other vendor out there.

--
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Re:BSD by colinrichardday · 2013-04-20 08:09 · Score: 1

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 by Billly+Gates · 2013-04-20 08:17 · Score: 1

Which is why the BSD license is so supperior. I wished FreeBSD 5.x didn't crumble and would beat linux. :-(
What is so damn evil about making money? WHat is so evil about feeding your family? Sorry but the world will not go into a communistic way of life and not use things which help consumers and businesses alike such as Office, sharepoint, ERP apps, games, or whatever. Sure you can use GNU but who do these people are to prevent businesses to streamline their processes with software or to tell us we can't have dreams of a better life by writting the next killer app?
This is not offtopic here, as GCC has clearly stated its goals were to prevent this now that they are popular. Well guess what? I see this no different than Microsoft of the old days which become popular on the cotails of another master (IBM) who then dictated which standards, versions, products, and other things at the OEM level. It is the reason we still have IE 6 in use today. GCC is no different as they are using whatever means necessary for the agenda. Just on hte opposite side of the socialism/capitalism scale. What we need is no politics or agendas and just use a product.

--
http://saveie6.com/
Re:BSD by dottrap · 2013-04-20 08:24 · Score: 1

In fact, the harm caused by gcc being GPL was the very reason Clang was invented.
The political motivations behind GPL forced gcc to be developed in such a way that it was monolith and impossible to build more advanced tooling that needed data from the intermediate stages of the compile process.
See Chandler Carruth's talk "Clang: Defending C++ from Murphy's Million Monkeys". At the beginning between 2:20 and 4:00, he quotes Richard Stallman's response to their proposed changes and demonstrates that using gcc is a non-starter.
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
Re:BSD by Billly+Gates · 2013-04-20 08:24 · Score: 1

So you feel they have a right to dictate to other users what they can do with their computers? Who do they think you are? Microsoft of old?
If someone wants to make money why should the compiler stop them? If someone wants to purchase software why should we stop them? What is so wrong about someone having a dream for a better life who wants to feed their kids?
Ide's want more integration, more apps want to make extension without giving away their trade secrets, more embedded devices want and need a compiler. It is hypocrtical for people like RMS to claim not to touch computers with non-free software as they take away freedom, yet work on products that do take away freedom from its users and yes developers who write commercial software use compiler and they have freedom too to feed their families and own homes and cars like everyone else.
GPLv3 has some real problems and htis is one of them. Slashdot 12 years ago was very anti-capitalistic as many of us were college students/basement dwellers. Now we are grownups with bills to pay. This silliness needs to stop and yes you are free not to use my software if I decide to charge for it so there you go.

--
http://saveie6.com/
Re:BSD by Jeremi · 2013-04-20 08:31 · Score: 1

Or do you mean, "acceptance by companies that are willing to take but unwilling to contribute"
There's nothing intrinsically wrong with being willing to take but unwilling to contribute, as long as the software's author is okay with that. Since software is free to replicate, it doesn't hurt the software's author or anyone else if a company uses it, and it might even help (e.g. if more companies use the software, it allows the software to be more thoroughly tested and debugged, and may help it become a de facto standard).
That said, if the author of the software doesn't like "freeloaders", the author can license under the GPL instead. Different strokes and all that.

--

I don't care if it's 90,000 hectares. That lake was not my doing.
Re:BSD by MikeBabcock · 2013-04-20 14:17 · Score: 1

Yawn, perspective issues.
The BSD license provides freedoms that can restrict others' freedoms (1).
The GPL allows only freedoms that keep everyone on an equal footing (2).
Pick your poison and stop spreading FUD.
1) If I take your BSD code and make a device that uses it, then stop supporting said device, you have no right to the changes I made to that code to fix bugs yourself in the future. You have less freedom than if it were GPL code.
2) If I want to use your GPL code, I have to also license the rest of my linked code GPL and thus lose my right to distribute my own code more restrictively.
Nothing is wrong with either of these things, but BSD people like to ignore the first, and GPL people like to ignore the second. Again, its all about perspective -- I prefer the GPL as a user. Every time.

--
- Michael T. Babcock (Yes, I blog)
Re:BSD by MikeBabcock · 2013-04-20 14:18 · Score: 1

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

--
- Michael T. Babcock (Yes, I blog)
Re:BSD by SuperKendall · 2013-04-20 14:25 · Score: 1

How many devices do you own with modified BSD licensed software on them that you can't fix because those changes are unreleased?
The point is the devices exist, and would not as they are without BSD. The GPL equivalent would not have simply have supplanted BSD.
As for "being able to fix them" I could certainly fix the BSD aspects of any of them.
More importantly, how would you know?
Know what? That's awfully broad. Know that they use BSD? You forget the licenses do generally require disclosure of use. Know that they are broken? Seems like that would be apparent if it was enough of a problem to matter.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Re:BSD by mark-t · 2013-04-20 14:41 · Score: 1

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

--
File under 'M' for 'Manic ranting'
Re:BSD by mark-t · 2013-04-20 15:04 · Score: 1

Nobody's forcing you to use the GPL if you think it's unsuitable for you, but really, the GPL is only trying to offer its freedoms to people who may be further removed from the original work, while BSD only offers its freedoms to immediate developers (who admittedly have an additional freedom to exclude people that they distribute to from having the same freedoms on any derivative work that they provide, while the GPL does not offer developers this freedom at a;;).
BSD is about something being free right now, but future versions of the software developed by other parties who may not agree with those terms could alter that arrangement. That the original source may be available doesn't make any modified future versions where the source has been closed up more free than they are. GPL is strictly about *keeping* something free, for as long as the copyright on the work lasts, at the costs of some freedoms for developers of derivative works. BSD is about something being free right now, and letting market forces alone determine whether the source code of future versions will continue to be available.

--
File under 'M' for 'Manic ranting'
Re:BSD by smellotron · 2013-04-20 18:07 · Score: 1

While you're at it, please denigrate PostgreSQL as well.
Re:BSD by TheRaven64 · 2013-04-20 20:59 · Score: 1

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

--
I am TheRaven on Soylent News
Re:BSD by thatkid_2002 · 2013-04-21 01:36 · Score: 1

For those interested, phatomfive is referring to this: http://fsfe.org/campaigns/gplv3/patents-and-gplv3.en.html#Explicit-patent-grant in regards to GPLv3 and patents.
Re:BSD by Guy+Harris · 2013-04-22 12:57 · Score: 1

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

Sure you can use GNU but who do these people are to prevent businesses to streamline their processes with software or to tell us we can't have dreams of a better life by writting the next killer app?
You can do both. Just don't, in the process, use other people's code in ways that they don't wish it to be used.

It's time to move on from GCC. by Anonymous Coward · 2013-04-20 02:43 · Score: 1

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

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

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

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

Re:It's time to move on from GCC. by cheesybagel · 2013-04-20 07:39 · Score: 1

Even if Clang was immensely successful it does not mean GCC would go away. Not anymore than having Chromium stopped people from using Firefox.
Re:It's time to move on from GCC. by cpghost · 2013-04-20 21:48 · Score: 2

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

--
cpghost at Cordula's Web.

OpenMp by darkHanzz · 2013-04-20 02:44 · Score: 1

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 by TheRaven64 · 2013-04-20 03:44 · Score: 1

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.

--
I am TheRaven on Soylent News

More complete? by goombah99 · 2013-04-20 02:46 · Score: 2

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

--
Some drink at the fountain of knowledge. Others just gargle.

Re:More complete? by AmiMoJo · 2013-04-20 04:35 · Score: 1

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!

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:More complete? by AmiMoJo · 2013-04-20 04:38 · Score: 1

P.S. Sheldon Cooper is that you?

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC

Re:Linux by _merlin · 2013-04-20 02:51 · Score: 4, 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.

Executable performance by Excelcia · 2013-04-20 02:55 · Score: 1

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 by KiloByte · 2013-04-20 03:43 · Score: 1

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

--
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Re:Executable performance by Excelcia · 2013-04-20 04:01 · 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 by Anonymous Coward · 2013-04-20 04:13 · Score: 1

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 by Anonymous Coward · 2013-04-20 04:58 · Score: 1

Have you tried "gcc -std=c99"? Just asking.
Re:Executable performance by cheesybagel · 2013-04-20 07:42 · Score: 1

Man that code is god awful. The most special cased POS I have seen in a long time.
Re:Executable performance by cheesybagel · 2013-04-20 07:45 · Score: 1

Even better "gcc -std=gnu99". I use that one.
Re:Executable performance by Jeremi · 2013-04-20 08:20 · Score: 1

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

--

I don't care if it's 90,000 hectares. That lake was not my doing.
Re:Executable performance by spitzak · 2013-04-20 11:51 · Score: 3, 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:Executable performance by Guy+Harris · 2013-04-20 12:52 · Score: 2

eh, gcc doesn't even follow C99, it's a half-assed C89
Are there any issues other than those mentioned in the GCC developers' status of C99 features in GCC page?

with all kinds of weird extension
Well, yes, if you specify --std=c99, "When a base standard is specified, the compiler accepts all programs following that standard plus those using GNU extensions that do not contradict it." You'd need -Wpedantic to get warnings about all GNU extensions and -pedantic-errors to get them as errors.
Re:Executable performance by Guy+Harris · 2013-04-20 14:15 · Score: 1

In my benchmarks llvm is universally faster.
And you missing a ton of platforms that clang supports. http://llvm.org/svn/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp
By "platforms" do you mean "instruction set architectures" or do you mean "particular variants of instruction set architectures on particular operating systems"? The person to whom you're replying listed ISAs, i.e. "platforms" in the former sense, not "platforms" in the latter sense.
The LLVM features page says LLVM includes "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore." However, the LLVM 3.2 release notes say "The CellSPU, MSP430, and XCore backends are experimental, and the CellSPU backend will be removed in LLVM 3.3.", and the LLVM 3.1 release notes say "The Alpha, Blackfin and SystemZ targets have been removed due to lack of maintenance.", as well as mentioning some little-endian MIPS support ("MIPS32 little-endian direct object code emission is functional." and "MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.").
So, whilst a lot of the "ton of platforms" are just different ISA versions or the same ISA on more than one OS, the list in "clang supports only i386, amd64, 32 bit arm, big-endian mips, s390" may be out of date, unless clang doesn't support all the ISAs that the LLVM backend does.)
Re:Executable performance by Guy+Harris · 2013-04-20 18:25 · Score: 1

Clang supports every backend that llvm does. What it doesn't do is automaticity find all the libraries and header files that are standard for a plat form. But you can specify any target that llvm supports.
GCC doesn't support all those targets because they need to be explicitly included in at compile time.
By "targets" do you mean "instruction set architectures" or "ISA version + OS"?
And by "support" do you mean "if you build GCC it automatically includes support for all those targets without having to configure them in" or do you mean "allows support for that target to be compiled in"? If you mean the former of those two definitions of "support", that's not generally what "support" means in this context; if you mean the latter, well, which of "X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore" aren't supported? On the host/target specific installation notes for GCC page, I don't see any explicit mention of Thumb, CellSPU, MSP430, or XCore ("SystemZ", i.e. z/Architecture or "64-bit System/3x0", is called "s390x" on that page), although the ARM options page for GCC mentions Thumb; I see references on the Web to an "mspgcc" project for the MSP430, but it's not part of the GCC release, and I see mentions of an "spu-gcc", but nothing about Xcore.
Re:Executable performance by iggymanz · 2013-04-21 01:36 · Score: 1

yeah, it almost works
Re:Executable performance by alexo · 2013-04-22 06:55 · Score: 1

While the latest MSVC produces fairly optimized x86 code (second to Intel's compiler), it's C++11 standard compliance is lacking.
See:
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
I had high expectations when Herb Sutter went to work for Microsoft but, so far, I am disappointed.

Re: Linux by Celarent+Darii · 2013-04-20 02:58 · Score: 2

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

This Entire Thread by interval1066 · 2013-04-20 03:16 · Score: 1

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

--
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'

Re:This Entire Thread by mevets · 2013-04-20 03:34 · Score: 1

Ironically mirroring gcc itself....

Re:Linux by DarkOx · 2013-04-20 03:20 · Score: 2

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.

--
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html

Re:Linux by gerddie · 2013-04-20 03:26 · Score: 2

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

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

This can be done with user space threads

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

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

Re:Linux by interval1066 · 2013-04-20 03:27 · Score: 2

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.

--
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'

Is there an in-print specification of C++11? by mark-t · 2013-04-20 03:39 · Score: 1

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?

--
File under 'M' for 'Manic ranting'

Re:Is there an in-print specification of C++11? by Fei · 2013-04-20 06:13 · 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.
Re:Is there an in-print specification of C++11? by kthreadd · 2013-04-20 22:44 · Score: 1

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

Sometimes I just don't get Slashdot mods... by Anonymous Coward · 2013-04-20 03:43 · Score: 1

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... by Em+Adespoton · 2013-04-20 05:22 · Score: 1

That would probably hold more weight not coming from AC.
It all has to do with the framing of the situation.
Let's see how it does coming from me...
I think it's great that Clang and LLVM are doing so well in this space, and applaud Apple, Adobe, Google, and all the other corporations who have contributed to it to get it to this point.
I'm also glad that GCC continues to exist and to progress. Diversity is good; people can choose the permissivity of their license, and choose the openness of their platform; there's a nice wide choice of options now.
Probably what the GP meant as well, but how they phrased it could really annoy a lot of people who interpreted it differently. Some people don't like it when others thank corporations/people for doing something that has benefited all, when they can see satellite issues that are to society's detriment in the long-run.
Personally, I find that the best way to get people/corps to do what you want is with a carrot and a hackamore -- leave the stick alone.
Re:Sometimes I just don't get Slashdot mods... by PhamNguyen · 2013-04-20 08:26 · Score: 1

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

Re:Linux by unixisc · 2013-04-20 03:58 · Score: 1

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 by BitZtream · 2013-04-20 04:01 · Score: 1

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.

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager

Re:AGPL: your rights to someone else's.... by Microlith · 2013-04-20 04:14 · Score: 2

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.

Just wait until... by Livius · 2013-04-20 04:30 · Score: 2

The next version will be NP-complete.

Re:Linux by kthreadd · 2013-04-20 04:36 · Score: 1

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

Re:AGPL: your rights to someone else's.... by Em+Adespoton · 2013-04-20 04:57 · Score: 1

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

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

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

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

Re:Linux by Kjella · 2013-04-20 05:03 · Score: 1

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

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

--
Live today, because you never know what tomorrow brings

Re:AGPL: your rights to someone else's.... by Microlith · 2013-04-20 05:08 · Score: 1

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

What freedom would that be?

Re:AGPL: your rights to someone else's.... by zakkudo · 2013-04-20 05:10 · Score: 1

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

A long time FSF supporter disagrees with you by SuperKendall · 2013-04-20 05:13 · 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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Nothing could be more wrong by SuperKendall · 2013-04-20 05:22 · Score: 4, 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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Re:Nothing could be more wrong by rtfa-troll · 2013-04-20 18:47 · Score: 1

Nothing could be further from the truth. By basing XCode on LLWM, it makes it EASIER to write third-party tools that can properly work over the source true with the same rich understanding of context.
Please don't get me wrong. I'm not questioning that LLVM is technically better in a number of ways, especially the ability to interoperate and especially in ways which are designed to encourage developers to get trapped using it.
What I'm wondering is, why concentrate on a project where the aim is to rewrite the entire compiler from zero when there was nothing in the GPL which would stop them from having using it to generate their entire proprietary code base. They could have forked GCC and provided an EGCS like clone which did what they wanted. The saving would have been huge.
The answer to that is simple. They would like to be able to push fully free operating systems like FreeBSD, Linux and OpenBSD out of the market. Their best way to do this is to get as much as possible of those systems BSD licensed so that they can build fully closed versions which move ahead of the rest of the system.

--
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Re:Nothing could be more wrong by SuperKendall · 2013-04-20 19:34 · Score: 3, 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.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Re:Linux by johnkzin · 2013-04-20 05:33 · Score: 1

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

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

Re:AGPL: your rights to someone else's.... by Microlith · 2013-04-20 06:05 · Score: 2

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

Re:Linux by jonwil · 2013-04-20 06:38 · Score: 1

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

Consider my points again. by SuperKendall · 2013-04-20 07:03 · Score: 3, 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!

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley

Re:AGPL: your rights to someone else's.... by cheesybagel · 2013-04-20 07:16 · Score: 1

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

Re:Linux by cheesybagel · 2013-04-20 07:26 · Score: 1

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

C++11: language and library? by Aidtopia · 2013-04-20 07:56 · Score: 1

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

Re:Linux by Billly+Gates · 2013-04-20 08:31 · Score: 1

Dos is EOL and obsolete. Get over it.

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

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

--
http://saveie6.com/

Re:AGPL: your rights to someone else's.... by stenvar · 2013-04-20 09:14 · Score: 1

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

Re:Linux by Jeremi · 2013-04-20 09:22 · Score: 1

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.

--

I don't care if it's 90,000 hectares. That lake was not my doing.

Re:Linux by tyrione · 2013-04-20 10:24 · Score: 1

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

Re:Linux by maccodemonkey · 2013-04-20 10:53 · Score: 1

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

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

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

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

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

Re:Linux by spitzak · 2013-04-20 11:42 · Score: 1

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

Re:AGPL: your rights to someone else's.... by martin-boundary · 2013-04-20 13:14 · Score: 1

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

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

Re:AGPL: your rights to someone else's.... by martin-boundary · 2013-04-20 13:28 · Score: 1

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

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

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

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

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

Re:Linux by Moridineas · 2013-04-20 14:12 · Score: 1

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

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

I disagree!

Re:AGPL: your rights to someone else's.... by MikeBabcock · 2013-04-20 14:12 · Score: 2

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

--
- Michael T. Babcock (Yes, I blog)

Re:Linux by Moridineas · 2013-04-20 14:14 · Score: 1

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: BSd in a compiler by glennrrr · 2013-04-20 14:18 · Score: 1

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

Re:Linux by jonwil · 2013-04-20 14:35 · Score: 1

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

Re:Linux by interval1066 · 2013-04-20 15:53 · Score: 1

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

--
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'

Re:Microsoft C++ 11 -- Not by kthreadd · 2013-04-20 22:42 · Score: 1

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

Re:Linux by O'Nazareth · 2013-04-21 01:45 · Score: 1

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

Re:Linux by odysseus_complex · 2013-04-21 07:38 · Score: 1

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

Re:AGPL: your rights to someone else's.... by exomondo · 2013-04-21 12:34 · Score: 1

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

Re:AGPL: your rights to someone else's.... by Em+Adespoton · 2013-04-23 04:54 · Score: 1

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

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

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

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

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

Re:AGPL: your rights to someone else's.... by Em+Adespoton · 2013-04-24 12:28 · Score: 1

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

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

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

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

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

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

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

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

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

Slashdot Mirror

LLVM Clang Compiler Now C++11 Feature Complete

174 of 291 comments (clear)