LLVM's Libc++ Now Has C++1Y Standard Library Support

← Back to Stories (view on slashdot.org)

LLVM's Libc++ Now Has C++1Y Standard Library Support

Posted by Unknown on Wednesday September 25, 2013 @04:25AM from the john-titor-joins-the-team dept.

An anonymous reader writes "LLVM's libc++ standard library (an alternative to GNU libstdc++) now has full support for C++1y, which is expected to become C++14 next year. Code merged this week implements the full C++1y standard library, with support for new language features in the Clang compiler frontend nearly complete." GCC has some support for the soon-to-be standard too. The C++ standards committee is expected to produce a more or less final draft in just a few weeks. The LLVM and GCC C++14 status pages both have links to the proposals for the new features.

161 comments

Min score:

Reason:

Sort:

!GNU/Linux by Dimwit · 2013-09-25 04:31 · Score: 5, Insightful

Now that Clang/LLVM has got this finished, I'm wondering what a system would look like with:
* Linux as the kernel
* Clang/LLVM as the system C/C++ compiler
* Heirloom Toolchest as the basic userland toolchain
* Wayland as the underlying display system
* musl as the system C library
That would be Linux, but would contain almost no GNU code. Not that I have anything against GNU, but the Heirloom Toolchest, Clang, and musl are all more standards compliant, smaller, and often faster than their GNU counterparts. I wonder what a Linux distribution like that would look like. I'd use it.
(I hate how "GNU's Not Unix!" is really becoming more and more true. Unix was about minimalism, and sometimes GNU seems like it's about stuffing everything possible into every tool.)

--
...but it's being eaten...by some...Linux or something...
1. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 04:54 · Score: 0
  
  It would be buried under the bodies of Richard Stallman's victims.
2. Re:!GNU/Linux by mark-t · 2013-09-25 04:58 · Score: 1, Informative
  
  X isn't GNU licensed... replacing it with Wayland would not decrease the amount of GNU code in the system.
  And GNU/Linux was a term coined by Stallman, probably because he may have been getting antsy about there not being an official GNU kernel yet, and so he figured he'd just appropriate another one without actually asking anybody... one that already existed with a GNU license, and was already in respectable condition. But Linux was never actually part of the GNU project, so calling it GNU/Linux strikes me as something of a misnomer. Like calling a Japanese car an American car just because it is driven in the USA.
  
  --
  File under 'M' for 'Manic ranting'
3. Re:!GNU/Linux by iluvcapra · 2013-09-25 05:00 · Score: 4, Interesting
  
  (I hate how "GNU's Not Unix!" is really becoming more and more true. Unix was about minimalism, and sometimes GNU seems like it's about stuffing everything possible into every tool.)
  If they didn't, it'd be easier for people from the proprietary and BSD-compliant-license land (like Apple and Google) to circumvent the spirit of the GPL. As long as you have to link into their code, or copy and paste it, they control what you can do with it. If you can just invoke whatever little piece of GPL code you want with arguments, you can progressively replace their tools without adding anything back to the original GCC tools -- if you can code around a bug in GNU project without submitting a patch to that project, that's adverse to the opening of the code in the first place. GCCs middle end is intentionally blurry, and not modularized into a separate tool, to keep people from taking their own parser and bolting GCC's optimizations onto it, just as an example.
  It follows that that changes to the tools, and the process of creating the tools, thus stays under the political thumb of various FSF-aligned BDFLs.
  
  --
  Don't blame me, I voted for Baltar.
4. Re:!GNU/Linux by sl4shd0rk · 2013-09-25 05:02 · Score: 2
  
  I'm wondering what a system would look like with
  Sounds like your describing OSX
  
  --
  Join the Slashcott! Feb 10 thru Feb 17!
5. Re:!GNU/Linux by AlphaWoIf_HK · 2013-09-25 05:06 · Score: 0
  
  It's 14:07; time to rummage through your soiled undies!
  
  --
  Da derp dee derp da teedly derpee derpee dum. Rated PG-13.
6. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 05:09 · Score: 1
  
  What? "GNU/Linux" refers to a combination of the Linux kernel and GNU userland utilities. Neither kernel or userland is much use without the other.
7. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 05:09 · Score: 0
  
  If they didn't, it'd be easier for people from the proprietary and BSD-compliant-license land (like Apple and Google) to circumvent the spirit of the GPL. As long as you have to link into their code, or copy and paste it, they control what you can do with it. If you can just invoke whatever little piece of GPL code you want with arguments, you can progressively replace their tools without adding anything back to the original GCC tools -- if you can code around a bug in GNU project without submitting a patch to that project, that's adverse to the opening of the code in the first place. GCCs middle end is intentionally blurry, and not modularized into a separate tool, to keep people from taking their own parser and bolting GCC's optimizations onto it, just as an example.
  It follows that that changes to the tools, and the process of creating the tools, thus stays under the political thumb of various FSF-aligned BDFLs.
  Which is the very opposite of what open software is meant to be about. Good job GNU project.
8. Re:!GNU/Linux by MrHm · 2013-09-25 05:12 · Score: 1
  
  * BSD as the kernel ...
9. Re:!GNU/Linux by TheRealMindChild · 2013-09-25 05:13 · Score: 2
  
  And GNU/Linux was a term coined by Stallman, probably because he may have been getting antsy about there not being an official GNU kernel yet, and so he figured he'd just appropriate another one without actually asking anybody
  
  It is very appropriate, but at the time, a whole lot of people counldn't understand why. Now you have Android. Linux kernel without the GNU userland. GNU/Linux and Android are not compatible
  
  --
  
  "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
10. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 05:13 · Score: 0
  
  Like other similarly licensed projects
  Likely better in manyways, but less useful overall because of a smaller community.
  For it to overtake/replace their GNU counterparts they don't need to be just better, but "killer app" better because they need to overcome the inertia of more popular projects. And no, not having a "more free" license is not that killer app.
  I think history has settled the OSS license debate. BSD style licenses don't grow your community. The big companies don't really contribute back. If your software ends up in a bunch of big commercial projects, but nothing flows back.. What's the point?
11. Re:!GNU/Linux by mark-t · 2013-09-25 05:19 · Score: 2
  
  No... it's not appropriate. It completely misrepresents the origins of LInux as having anything to do with the GNU project.
  Linux was GNU licensed, but was not *ever* part of the GNU project. If GNU made a distro of LInux it would be reasonable to call that distro GNU/Linux, but afaik they do not. The term would still be inapplicable to other distros, however.
  
  --
  File under 'M' for 'Manic ranting'
12. Re:!GNU/Linux by mark-t · 2013-09-25 05:24 · Score: 2
  
  Nobody will argue that the utilities that came with Linux were all GNU, but that does not make it GNU/Linux any more than the system that I used while I was at university should have been called GNU/HPUX because the system administrator had replaced all the standard HPUX tools with GNU ones.
  Linux was originally developed with and for the tools that came with Minix at the time... almost all of which were also GNU, but nobody ever called Minux GNU/Minix. It's more the case that the GNU tools were ported to Linux just as they were to Minix.
  
  --
  File under 'M' for 'Manic ranting'
13. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 05:26 · Score: 0
  
  Wasn't the name a reference to the use of the GNU toolset in Linux distributions as GNU with/on Linux?
14. Re:!GNU/Linux by mark-t · 2013-09-25 05:36 · Score: 1
  
  That is the justification is frequently used, but if you completely replace the toolchain of any unix-like operating system with GNU ones, that does not make that particular system suddenly GNU. The GNU tools were all ported to Linux, but Linux is not and has never been part of the GNU project, so calling it GNU/Linux is a misnomer.
  
  --
  File under 'M' for 'Manic ranting'
15. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 05:44 · Score: 0
  
  GNU/BSD?
16. Re:!GNU/Linux by stenvar · 2013-09-25 05:54 · Score: 2
  
  Not that I have anything against GNU, but the Heirloom Toolchest, Clang, and musl are all more standards compliant, smaller, and often faster than their GNU counterparts
  They also lack tons of useful features, and a lot of stuff simply wouldn't run on such a system.
17. Re:!GNU/Linux by K.+S.+Kyosuke · 2013-09-25 06:01 · Score: 1
  
  X isn't GNU licensed... replacing it with Wayland would not decrease the amount of GNU code in the system.
  
  You're obviously confusing GNU system code and GPL'd code.
  
  --
  Ezekiel 23:20
18. Re:!GNU/Linux by iluvcapra · 2013-09-25 06:01 · Score: 1
  
  I dunno, I do develop software, what's the matter with my account?
  
  --
  Don't blame me, I voted for Baltar.
19. Re:!GNU/Linux by TheRealMindChild · 2013-09-25 06:05 · Score: 1
  
  Would you rather it be called "GNU Userland/Linux"? In the same vein, would you be ok with Windows RT being called "Windows 8"?
  
  --
  
  "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
20. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 06:06 · Score: 0
  
  Sometimes OpenWRT is called a Busybox/Linux distro, because the GNU coreutils have been replaced by Busybox.
  In this case, the advantage is not that Busybox is faster, but that it takes less flash storage.
21. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 06:31 · Score: 0, Troll
  
  7 in 10 Japanese cars sold in U.S. made in N. America
  And on the flip side...
  Most 'made in U.S.A.' cars are Japanese
  So, "Japanese cars" and "American cars" are basically synonyms.
22. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 06:35 · Score: 0
  
  I'd rather it be called "Linux".
23. Re:!GNU/Linux by lgw · 2013-09-25 06:36 · Score: 2
  
  The GNU project is forcing a separation between the GPL world and the BSD world. Mainstream Linux will follow the BSD path. That will marginalize the GPL world over time, IMO.
  
  It follows that that changes to the tools, and the process of creating the tools, thus stays under the political thumb of various FSF-aligned BDFLs.
  I believe a heavy hammer is descending towards said thumb.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
24. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 06:38 · Score: 1
  
  Yes.
  And yes again.
  Although I'd be interested in an opposite project, with a Linux kernel and a BSD userland (especially the BSD libc).
25. Re:!GNU/Linux by Raenex · 2013-09-25 06:39 · Score: 1
  
  No... it's not appropriate. It completely misrepresents the origins of LInux as having anything to do with the GNU project.
  I thought it was petty on Stallman's part to try and call it GNU/Linux, but without the GNU tools there is no Linux. I can see why it bothered Stallman that all the glory and name recognition of Linux went to Linus and his kernel.
26. Re: !GNU/Linux by Anonymous Coward · 2013-09-25 06:42 · Score: 0
  
  the most amusing part of this debate is that BSD advocates have become FAR more zealous about licenses than GPLers.
27. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 06:50 · Score: 0
  
  GNU is like Wozniak and Linux is like Steve Jobs....Linux will keep doing great things but GNU is past its usefulness.
28. Re:!GNU/Linux by iluvcapra · 2013-09-25 07:12 · Score: 2
  
  I think it was always contingent on who uses the software and who develops it. For a long time GPL-land was superior because it could collect a lot of small developers' free time, and these people were developing tools for their own use, thus they all had incentives to stay within the ecosystem and they all benefited.
  In a world where large corporations are pouring hundreds of paid developers into OSS projects, using the OSS licensing not for ideological reasons but for business model reasons, the GPL paradigm has a lot of trouble competing, particularly on tools where the set of people who are users is much larger, or mostly disjoint, from the set of people who are developers.
  The political stuff in GPL-land is a symptom of the ideological mission, and the perception on the part of many misguided BDFLs (by no means all of them) that they're the only game in town and they don't have to compete for coder-hours with other projects.
  
  --
  Don't blame me, I voted for Baltar.
29. Re: !GNU/Linux by Anonymous Coward · 2013-09-25 07:16 · Score: 0
  
  "Linux is like Steve Jobs."
  Yep. Six feet under and going nowhere.
30. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 07:17 · Score: 0
  
  How can you make a statement like that when the Linux kernel itself is GPL? :P
31. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 07:18 · Score: 1
  
  "Nobody will argue that the utilities that came with Linux were all GNU, but that does not make it GNU/Linux "
  Neither does it make an entire OS Linux just because the kernel is Linux. That being said, I'll argue it. The user space tools (which you are calling utilities) weren't all GNU. Some distributions have a BSD based init system while others had a AT&T System 5 based init. Neither of those is from GNU, and yet almost all but Gentoo had one of them until systemd came along. While it is indeed true that many of the core utilities were/are from GNU, many of the other Linux utilities are not from GNU.
  
  All of that being said, calling it GNU/Linux rather than Linux is better than calling a whole OS Linux when only the kernel and util-linux are actually Linux, or calling it Linux/BSD/GNU or Linux/System5/GNU. None of these are accurate. Of course, the absolute best way to describe any Linux based distribution is to call it a Linux based distribution. Why? Well lets start with the fact that a distribution is much more than on Operating System and certainly more than just a kernel.
  
  To recap: Just call it a frigging Linux based distribution, but only say Linux when you mean the kernel and only the kernel. If you must err on the side of brevity, GNU/Linux is best, since even the source that isn't from GNU has been compiled by GCC up until now, at least.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
32. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 07:20 · Score: 2
  
  You're logged into it.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
33. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 07:27 · Score: 0
  
  We are not calling the KERNEL GNU/Linux. We are calling the operating system formed by gnu libraries, toolset and linux GNU/Linux.
  If you can't see the logic in that, I'm very sorry for you.
  PS: Very fun to see you reply and argue with everybody, good old slashdot.
34. Re:!GNU/Linux by lgw · 2013-09-25 07:40 · Score: 1
  
  Yep, stuff of practical real-world benefit always wins over idealism in the end, and that tension is at the heart of the GPL/BSD split.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
35. Re:!GNU/Linux by jones_supa · 2013-09-25 07:46 · Score: 1
  
  The basic set of UNIX command line tools is the only area on which a Linux operating system depends on GNU.
36. Re:!GNU/Linux by mark-t · 2013-09-25 07:48 · Score: 1
  
  This has nothing to with the kernel itself or the suite of tools it is distributed with. It has to do with calling something GNU that isn't GNU. It compeletely misrepresents what LInux originally was... which is a free replacement for Minix. It was Stallman's decision to call it GNU/Linux, which, I'd like to point out, he did so without asking anybody, effectively trying to appropriate Linux as if it were part of the GNU project all along even... though, again, it never was.
  If I write my own OS and released it under a GNU license, just because I bundle it with GNU tools, that doesn't suddenly make it GNU/BlahOS. It makes it BlahOS bundled with GNU tools that were ported to it.
  I used an HPUX system in university that the sysadmin had replaced all the starndard tools with GNU ones... that didn't make that system GNU/HPUX.
  
  --
  File under 'M' for 'Manic ranting'
37. Re:!GNU/Linux by larry+bagina · 2013-09-25 07:50 · Score: 1
  
  Android and GNU/Linux aren't "compatible" for reasons that have nothing to do with the GNU userland (which runs quite fine on android).
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
38. Re:!GNU/Linux by mark-t · 2013-09-25 07:54 · Score: 1
  
  ...calling it GNU/Linux rather than Linux is better than calling a whole OS Linux when only the kernel and util-linux are actually Linux
  I used an HPUX system in university where the sysadmin had replaced every last command line tool with GNU counterparts.
  The system didn't spontaneously become a GNU/HPUX system.... it was still all HPUX, The GNU tools has just been ported to run on it.
  Likewise, the GNU tools have all been ported to run on Linux. That doesn't make it GNU/Linux.
  
  --
  File under 'M' for 'Manic ranting'
39. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 08:32 · Score: 1
  
  "The system didn't spontaneously become a GNU/HPUX system"
  Of course it didn't happen spontaneously. It became a GNU/HPUX system through a lot of hard work on the part of the system administrator.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
40. Re:!GNU/Linux by samkass · 2013-09-25 08:34 · Score: 1
  
  Why are you defining "Linux" as just the kernel? The original meaning was the entire OS, with the phrase "Linux kernel" referring to just the kernel. If you want to err on the side of brevity, "Linux" is accurate, "GNU/Linux" is what RMS wants everyone to call it, and "GNU/MIT/BSD/Apache/Canonical/RHEL/SUSE/Linux" would be more accurate. I'd advise ignoring the last two options and calling the OS by it's original name-- Linux.
  
  --
  E pluribus unum
41. Re:!GNU/Linux by mark-t · 2013-09-25 08:37 · Score: 1
  
  My point was that it was *NEVER* GNU/HPUX.... It was always just an HPUX with the GNU tools ported to it and installed on it.
  
  --
  File under 'M' for 'Manic ranting'
42. Re:!GNU/Linux by Bengie · 2013-09-25 08:38 · Score: 1
  
  And you've convinced yourself that when someone copies your code, you no longer have access to your code?
  
  You seem to have applied "single responsibility" beyond its intended scope
43. Re: !GNU/Linux by Anonymous Coward · 2013-09-25 08:39 · Score: 0
  
  In general I agree with you. The closest right now would probably be Aboriginal, which is moving in that direction but with toybox rather than heirloom. One thing missing in your list of replacements is the BSD binutils replacement (elftoolchain)... or perhaps LLVM got its own now?
44. Re:!GNU/Linux by dfghjk · 2013-09-25 08:44 · Score: 1
  
  "GNU/Linux" is Stallman's desire to take credit for something Linus and large group of programmers did that Stallman failed to do.
45. Re:!GNU/Linux by dfghjk · 2013-09-25 08:47 · Score: 2
  
  Nothing in the GPL stipulates that the FSF gets to rename your project if you use some of their code. It has only occurred in this case due to Stallman's jealousy and no one should entertain his ego. GNU/Linux is a term that should be universally rejected, software freedom demands it.
46. Re:!GNU/Linux by dfghjk · 2013-09-25 08:52 · Score: 1
  
  "All of that being said, calling it GNU/Linux rather than Linux is better than calling a whole OS Linux when only the kernel and util-linux are actually Linux, or calling it Linux/BSD/GNU or Linux/System5/GNU. None of these are accurate."
  The "it" you are referring to doesn't need to be referred to at all. If you want to talk components, there are names for those. Otherwise use the name of the distribution. No need for contrived names for subsets when those names are chosen to satisfy an agenda. Respect the choices made by the people who have done the work, GNU/Linux was coined by someone NOT responsible for the work.
47. Re:!GNU/Linux by dfghjk · 2013-09-25 08:53 · Score: 1
  
  "GNU/Linux and Android are not compatible"
  There is no such thing as "GNU/Linux".
48. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 08:57 · Score: 1
  
  "Why are you defining "Linux" as just the kernel? The original meaning was the entire OS, with the phrase "Linux kernel" referring to just the kernel."
  If you really want to know what is actually Linux, here is the link. It doesn't actually matter what it was first called, but you are wrong. It was actually first called: a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.
  
  "I'd advise ignoring the last two options and calling the OS by it's original name-- Linux."
  Again, it would be awesome advice if that was the original name in the first place. It wasn't.
  
  Flash forward to today. Linux is the kernel. You can use git to get Linux as follows git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git See. It's not called linux-kernel.git, just linux.git. (don't be confused by the kernel.org domain name. As it turns out there is lots of stuff not related to the kernel on kernel.org and lots of domains without kernel in the name where you can get the linux source, which again, contains the kernel)
  
  To make an OS you need user space tools, and you cannot make an OS using only Linux and the util-linux user space tools. Period.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
49. Re:!GNU/Linux by dfghjk · 2013-09-25 08:57 · Score: 1
  
  Never, ever did the "userland" need to be mentioned in the name of the product until Stallman declared it so. There is no need for it now.
  There is a need for distinct products, such as in your example, to have distinct names.
  Linux distributions have distinct names and Stallman doesn't get to overrule what those names are. If he really cared about freedom he'd be on the other side of his argument.
50. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 08:58 · Score: 1
  
  ... and my point was, of course it was! It became that by your own admission when GNU was married with HPUX to create a GNU/HPUX system
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
51. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 09:00 · Score: 1
  
  "Respect the choices made by the people who have done the work, GNU/Linux was coined by someone NOT responsible for the work."
  Are you on drugs or something? If not:then I recommend you start doing drugs immediately.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
52. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 09:04 · Score: 0
  
  Er the point is that the Linux kernel is indeed useful without the GNU userland.
  The GNU userland however has no usable GNU kernel it can shack up with on the rebound.
53. Re:!GNU/Linux by mark-t · 2013-09-25 09:22 · Score: 1
  
  Negtaive.... labelling it GNU would imply that it has some affiliation with the GNU project. HPUX does not. Neither did the sysadmin.
  
  --
  File under 'M' for 'Manic ranting'
54. Re:!GNU/Linux by loufoque · 2013-09-25 09:38 · Score: 1
  
  As of this writing, the reference toolchain for android is GCC 4.7.
55. Re:!GNU/Linux by iluvcapra · 2013-09-25 09:44 · Score: 1
  
  It's a perfect example, it's non-modular and monolithic, requiring recompiles of the entire kernel to include support for new hardware and filesystems. This is their way of making it as hard as possible for hardware vendors to interact with a Linux kernel without publishing driver source, and preferably getting that source into Linus's tree. In Linux's case the intentional blurriness is in the Linux kernel ABI, which is overtly kept informal and unstable.
  
  --
  Don't blame me, I voted for Baltar.
56. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 09:47 · Score: 0
  
  ...but the GNU code did you frigging moron.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
57. Re:!GNU/Linux by iluvcapra · 2013-09-25 09:49 · Score: 1
  
  No, you misunderstand. When someone copies your code, you lose access to any patches they may make. GNU effectively requires patches to be published, as a condition of redistribution. BSD and proprietary licenses do not, so GNU encourages a more free time/community-based approach that consolidates projects, because forking is almost always a waste or energy and it's almost always better to just submit your patches to a single repository.
  It starts being less fun when the guy who runs the project won't accept your patches, because he doesn't consider your particular bug fixes a priority, or your features don't mesh with the maintainer's vision for how the tool should work. This is why Apple switched to LLVM, for example -- they wanted parser and static analysis tools that were made of distinct components, so they be used interactively with a closed-source GUI, and this was contrary to the overall goals of the GCC project.
  
  --
  Don't blame me, I voted for Baltar.
58. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 10:36 · Score: 0
  
  Unix was about minimalism, and sometimes GNU seems like it's about stuffing everything possible into every tool.
  I take it you've read A Generation Lost in the Bazaar?
59. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 10:53 · Score: 0
  
  There are plenty of Linux distributions without GNU tools.
  Android is the most famous but as soon as you step away from anything server/desktop it becomes increasingly common.
60. Re:!GNU/Linux by mark-t · 2013-09-25 11:10 · Score: 1
  
  The GNU code was compiled for and then run on that particular platform. The platform does not become GNU just because one is running GNU tools on it any more than a somebody running a JVM on windows turns their windows box into a Java machine. It's still just a windows machine that is running Java.
  Similarly, I used an HPUX that had GNU tools when I was at university. That doesn't make it GNU/HPUX, because it had no affiliation with the GNU project. It might still be GNU code, but the platform it was running on was still just plain old HPUX, because that was what the GNU programs were compiled for and run on. When used in a title, "GNU" implies that it is intended to be, officially or unofficially, considered part of the GNU project. HPUX is not. Linux is not.
  Namecalling doesn't make you more right, by the way... I've presented factual basis for asserting that calling Linux GNU/LInux, even with a full suite of GNU tools, is mislabeling, misleading, and just plain wrong. Your continued assertion to the contrary does nothing to alter that. GNU code can be ported to practically every desktop or workstation computer platform currently in existence... but in the end it's still just GNU code running *ON* that particular platform.
  That's why Linux is just Linux... because the kernel is still Linux, and all of the other GNU code just happens to run nicely inside of that.
  I think, however, we're done. Unless you have new points to raise... but owing to the succinctness of your last comment, I expect that's probably not the case. If you insist on having the final word, however... knock yourself out.
  
  --
  File under 'M' for 'Manic ranting'
61. Re:!GNU/Linux by mark-t · 2013-09-25 11:18 · Score: 1
  
  Yes... *THAT* is my point. Thank you for putting it much more succinctly than I.
  
  --
  File under 'M' for 'Manic ranting'
62. Re:!GNU/Linux by Zero__Kelvin · 2013-09-25 11:26 · Score: 0
  
  Just shut the fuck up. You are a straight frigging idiot.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
63. Re:!GNU/Linux by Raenex · 2013-09-25 11:34 · Score: 1
  
  There are plenty of Linux distributions without GNU tools.
  That took a long time to happen. Linux gained fame as a kernel combined with the GNU tools over 20 years ago. Stallman's complaint originated early on. Wikipedia helpfully has a history section on it.
64. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 13:25 · Score: 0
  
  Although I'd be interested in an opposite project, with a Linux kernel and a BSD userland (especially the BSD libc).
  I've been wanting this since I discovered FreeBSD. But I probably haven't the skills and surely don't have the time. :(
65. Re:!GNU/Linux by nbritton · 2013-09-25 15:54 · Score: 1
  
  I hate how "GNU's Not Unix!" is really becoming more and more true. Unix was about minimalism, and sometimes GNU seems like it's about stuffing everything possible into every tool.
  GNU is written with emacs, which is written in Lisp, by Richard Stallman. As is the case with most infernal Lispers, they don't subscribe to the Unix way of life. Stallman settled on Linux simply because emacs didn't have a bootloader yet; thank god eMach never came to fruition. :-P
  I wish someone would port 4.4BSD-Lite to Linux... I want to run FreeBSD with a Linux kernel.
66. Re:!GNU/Linux by cas2000 · 2013-09-25 16:01 · Score: 1
  
  i used to think of the solaris boxes i installed all the GNU tools on as GNU/Solaris.
  It's a pretty good and succinct way of describing solaris with decent versions of the standard utilities (because the standard solaris ones are shit).
  these days, it's hard to think of a reason why i'd even want to install solaris rather than linux.
67. Re:!GNU/Linux by Anonymous Coward · 2013-09-25 22:38 · Score: 0
  
  As long as you have to link into their code, or copy and paste it, they control what you can do with it.
  Only if "what you can do with it" involves distribution, and "they" don't actually control anything. You do.
  You know (or should know, unless you're incompetent) full well when picking any software component what the license for said component is. If you don't agree with it, use something else, or write it yourself.
  Any use of said component, as long as it's not distributed to anyone else, is not governed in any shape or form by the license, whether it's based on BSD or GPL.
68. Re:!GNU/Linux by jeremyp · 2013-09-25 22:56 · Score: 1
  
  Just call it a frigging Linux based distribution, but only say Linux when you mean the kernel and only the kernel. If you must err on the side of brevity, GNU/Linux is best, since even the source that isn't from GNU has been compiled by GCC up until now, at least.
  GNU/Linux might be best, but it's not correct. There are many components of the average distro that are not GNU e.g. the GUI whether it be Gnome or KDE or XFCE or whatever.
  "GNU/Linux" has also lost the battle with respect to common usage. When people say "Linux" they are usually referring to the whole distro and if you go round insisting on GNU/Linux, you'll end up having to explain what you mean almost every time.
  It's also rather bizarre to name a package after the compiler with which the development team compiles it.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
69. Re: !GNU/Linux by staalmannen · 2013-09-26 02:28 · Score: 1
  
  There has at least been some at getting some binutils replacements within the LLVM project. No idea how complete this is at the moment....
70. Re:!GNU/Linux by david_thornley · 2013-09-26 02:47 · Score: 1
  
  I don't understand that argument. The HPUX kernel has nothing to do with the Gnu project. Neither does the Linux kernel, except that Linus likes GPLv2. If Linux were a Gnu project, it would make sense to just refer to a Gnu OS. (Personally, I generally use phrases like "Linux distro", "Linux kernel", "Gnu userland", "X windows", and avoid the whole Gnu/Linux controversy that way.)
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
71. Re:!GNU/Linux by Anonymous Coward · 2013-09-26 02:59 · Score: 0
  
  That is not true.
  Linux requires both a libc and standard command line tools in order to be a POSIX compliant operating system.
  Both of these usually come from the GNU project. (glibc and coreutils)
72. Re:!GNU/Linux by david_thornley · 2013-09-26 03:13 · Score: 1
  
  Except that the Gnu project was intended for real-world benefit. The idea was to create a body of GPLed code that would be so useful people would write free software using Gnu code rather than reject that body of code to write proprietary software. Free software is better for the world than equivalent proprietary software, other things being equal. This has had some success.
  The Gnu project has made many compromises and concessions from ideological purity. The LGPL was one such. So are the licensing terms that allow me to use YACC-generated parsers compiled with GCC and using glibc to make proprietary code.
  There is plenty of idealism in both the GPL and BSD-like camps. I've seen enough people on /. complain that the GPL imposes restrictions, and therefore isn't really free, and is therefore evil. Some BSD fans seem to prefer their code be used in proprietary/closed-source software than in GPLed software. Stallman, incidentally, considers the modified BSD license (no advertising clause) as a free license, and the GPL FAQ recommends such licenses in some cases. This is in contrast to the license fanbois on both sides.
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
73. Re:!GNU/Linux by Zero__Kelvin · 2013-09-26 04:16 · Score: 1
  
  "GNU/Linux might be best, but it's not correct. "
  You quoted what I wrote, so I have to assume you don't know what the word "err" means.
  
  ""GNU/Linux" has also lost the battle with respect to common usage. "
  This thread isn't about common usage; it is about correct usage. It is very common today to hear the phrase "My bad", but that doesn't make it correct.
  
  " if you go round insisting on GNU/Linux, you'll end up having to explain what you mean almost every time."
  Again, you seem to miss the point. It is an error to call it GNU/Linux, and as I already stated, calling it a Linux based distribution is best. If you just call it Linux, you won't have to explain a thing; the problem is they will have the wrong idea in their mind, to wit, that a Linux based distribution and Linux are one and the same.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
74. Re:!GNU/Linux by jones_supa · 2013-09-26 04:23 · Score: 1
  
  That is true. Thank you for the correction.
75. Re:!GNU/Linux by lgw · 2013-09-26 05:02 · Score: 1
  
  Sure, but if you diff the GPL and BSD philosophies, the BSD approach is more "we want anyone to be able to use our code for anything" while GPL is "you must give back". The more practical approach will win out in the end.
  For whatever anecdotes are worth, every place I've ever worked, the hurdles to using BSD-style licensed code were small, just some process by which legal checks that it really is a BSD-style license. GPL code, on the other hand, was always more effort to grapple with legal to distribute than to just write it again, or find an alternative.
  
  --
  Socialism: a lie told by totalitarians and believed by fools.
76. Re:!GNU/Linux by Anonymous Coward · 2013-09-26 08:22 · Score: 0
  
  You can use git to get Linux as follows git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git See. It's not called linux-kernel.git, just linux.git. (don't be confused by the kernel.org domain name.....
  And don't be confused by the "linux/kernel" in the url either... and don't be confused by being told not to be confused. I didn't realize that urls were such great evidence for defining names. I guess Linux and Windows are also defined by the drivers of the company I work for, since we have a "linux" and "windows" repository, but didn't bother to call them "linux-driver" and "windows-driver."
77. Re:!GNU/Linux by Zero__Kelvin · 2013-09-26 08:54 · Score: 1
  
  I wasn't really telling you not to be confused specifically. I fully expect a person that is unable to create a Slashdot account to be easily confused, so feel free to have at it.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
78. Re:!GNU/Linux by david_thornley · 2013-09-26 15:49 · Score: 1
  
  On the one hand, I think you're being a bit short-sighted on practicality. On the other, the desire not to maintain a fork seems to be getting lots of people to kick BSD-licensed changes back upstream.
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
GNU excitement by tuppe666 · 2013-09-25 04:36 · Score: 1

Now that Clang/LLVM has got this finished, I'm wondering what a system would look like with:
... * Clang/LLVM as the system C/C++ compiler
Slower
1. Re:GNU excitement by Anonymous Coward · 2013-09-25 04:50 · Score: 0
  
  but the point is that very few people care, and this will be optimized in due time.
  Clang will improve the code quality, which is more important.
2. Re:GNU excitement by Anonymous Coward · 2013-09-25 05:02 · Score: 3, Informative
  
  Faster at compiling at least. And there's lots of code floating around that was compiled in GCC version 4.3 or earlier - Clang/LLVM-compiled code runs circles around that. GCC had a huge speed boost at version 4.4 which took time for LLVM to catch up to. The latest version of LLVM is actually very competitive against the latest GCC except where the GCC code makes use of OpenMP (which LLVM is still busy implementing).
3. Re:GNU excitement by iluvcapra · 2013-09-25 05:07 · Score: 1
  
  I imagine most of the people invoking clang these days are using to do what OpenMP does.
  
  --
  Don't blame me, I voted for Baltar.
4. Re:GNU excitement by iluvcapra · 2013-09-25 05:07 · Score: 1
  
  Correction: I imagine most of the people invoking clang these days are using dispatch.h to do what OpenMP does.
  
  --
  Don't blame me, I voted for Baltar.
5. Re:GNU excitement by KiloByte · 2013-09-25 05:16 · Score: 2
  
  The latest version of LLVM is actually very competitive against the latest GCC except where the GCC code makes use of OpenMP (which LLVM is still busy implementing).
  For the values of "competitive" of "around 1 level of optimization slower" on the average (although particular cases vary widely). Granted, gcc tends to compile around that level of optimization slower in return, but for production code, you compile once run many.
  And on the high end of optimizations... gcc compiles one piece of code with LTO in 40 minutes on a 256MB raspberry pi, while clang OOMed after several hours on my main box (8MB ram + 8MB ssd swap).
  And comparing current clang with ancient gcc... what's the point? Newsflash: modern gcc runs circles around that too.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
6. Re:GNU excitement by Sectrish · 2013-09-25 05:22 · Score: 5, Interesting
  
  Now that Clang/LLVM has got this finished, I'm wondering what a system would look like with:
  ... * Clang/LLVM as the system C/C++ compiler
  Slower
  I'm developing a tiny game engine in C(11) and I've built profiling into the core, and I profile many of the math-heavy parts separately as well. Clang 3.3 actually almost always does better than gcc 4.8 here. Not by much, but there you have it. You should take a look at the SLP vectorizer, which will come enabled in -O3 as of Clang 3.4 but can already be enable separately with -fslp-vectorize.
  So for single threaded code I'm already leaning towards Clang. OpenMP is going to get integrated as well, as of then, all bets are off. Exiting times to be a C/C++ dev... (or any other kind, for that matter, LuaJIT never ceases to amaze me).
7. Re:GNU excitement by Fnordulicious · 2013-09-25 05:23 · Score: 1
  
  And on the high end of optimizations... gcc compiles one piece of code with LTO in 40 minutes on a 256MB raspberry pi, while clang OOMed after several hours on my main box (8MB ram + 8MB ssd swap).
  You're compiling on a system with only 8 MB of ram? Are you still stuck in 1993 or something? Memory restrictions in embedded systems is one thing, but on a development machine it seems bizarre. Like cutting off your legs just to see how slow you can run a marathon on stumps.
8. Re:GNU excitement by K.+S.+Kyosuke · 2013-09-25 05:55 · Score: 1
  
  You should take a look at the SLP vectorizer
  Aren't vectorizers a serious language smell? Once you're basically forced to start guesstimating what is the mutable-variable-manipulating C-level program trying to actually do, all bets are off what the vectorizer is going to be able to deduce.
  
  --
  Ezekiel 23:20
9. Re:GNU excitement by Raenex · 2013-09-25 06:24 · Score: 1
  
  I think it's pretty obvious he meant 8GB.
10. Re:GNU excitement by epyT-R · 2013-09-25 07:44 · Score: 1
  
  Depends what you mean by 'code quality.' To me, one of its characteristics is speed.
11. Re:GNU excitement by Anonymous Coward · 2013-09-25 07:48 · Score: 0
  
  Well, every major CPU instruction set now has special optimized instruction set extensions for vector math, so you can either use the vectorizer or start writing embedded assembly. Or just have your code run slower, I guess.
12. Re:GNU excitement by cyfer2000 · 2013-09-25 08:09 · Score: 1
  
  I thought LLVM won't implement OpenMP because OpenMP could not scale to hundreds of cores nicely. LLVM was looking for something better than OpenMP. Has the wind changed?
  
  --
  There is a spark in every single flame bait point.
13. Re:GNU excitement by DrXym · 2013-09-25 08:18 · Score: 1
  
  Slower. For a time. Chances are it would provide the motivation for someone to optimize it even more.
14. Re:GNU excitement by K.+S.+Kyosuke · 2013-09-25 08:42 · Score: 1
  
  so you can either use the vectorizer or start writing embedded assembly
  This is a false dichotomy, if I've ever seen one. There are languages such as APL, J, K, etc. that don't need vectorizers and still can generate native code with vector instructions, simply because their high-level operators already contain the algebraic information that the vectorizers for C/C++ are trying to recover from loopy code.
  
  --
  Ezekiel 23:20
15. Re:GNU excitement by Anonymous Coward · 2013-09-25 08:50 · Score: 0
  
  I thought LLVM won't implement OpenMP because OpenMP could not scale to hundreds of cores nicely. LLVM was looking for something better than OpenMP. Has the wind changed?
  No LLVM developer has said any such thing. Here is the llvm mailing list. Feel free to point a where they said they were won't implement it.
16. Re:GNU excitement by Anonymous Coward · 2013-09-25 08:53 · Score: 0
  
  This is a false dichotomy, if I've ever seen one. There are languages such as APL, J, K, etc. that don't need vectorizers and still can generate native code with vector instructions, simply because their high-level operators already contain the algebraic information that the vectorizers for C/C++ are trying to recover from loopy code.
  This is a false dichotomy. If you write a APL, J, K, etc. compiler using LLVM it will use the same vectorizes that the Clang front end uses.
17. Re:GNU excitement by loufoque · 2013-09-25 09:34 · Score: 1
  
  From my experience with both the latest GCC and Clang, Clang is about two times faster and uses 25% less memory (40% less than GCC 4.8 which somehow uses much more memory than its predecessors).
  Optimization with clang is also slightly better. It depends what sort of optimization you're looking for, but Clang is quite good at getting rid of the abstraction penalty, which is the only thing I really care about.
18. Re:GNU excitement by loufoque · 2013-09-25 09:36 · Score: 1
  
  The correct way to use SIMD is to use intrinsics.
  There are also libraries that wrap the functionality portably.
  Using inline assembly is about the worst thing you can do, unless you don't care about composability at all.
19. Re:GNU excitement by loufoque · 2013-09-25 09:38 · Score: 1
  
  The only people that think this is a good idea are the people who don't understand how a processor actually works.
20. Re:GNU excitement by SpaceLifeForm · 2013-09-25 10:25 · Score: 1
  
  (40% less than GCC 4.8 which somehow uses much more memory than its predecessors)
  GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003. Link
  C++ programs are fatter than pure C. So, now, GCC is fatter.
  
  --
  You are being MICROattacked, from various angles, in a SOFT manner.
21. Re:GNU excitement by Anonymous Coward · 2013-09-25 10:42 · Score: 0
  
  Standards compliant.
  One of GGCs flaws is that it allows things that aren't really C. This makes porting things written for GCC to more esoteric platforms that GCC doesn't support a bit problematic.
  Code that doesn't work if you change compiler doesn't have high quality.
22. Re:GNU excitement by bames53 · 2013-09-25 12:47 · Score: 1
  
  Clang is an open source project; People want OpenMP so they're implementing it. The OpenMP work on clang is being done by Intel engineers. I believe it was Intel that also did an initial prototype of C++AMP on Clang as well.
23. Re:GNU excitement by K.+S.+Kyosuke · 2013-09-25 22:28 · Score: 1
  
  The only people that think this is a good idea are the people who don't understand how a processor actually works.
  Exactly, autovectorizers of C and C++ code really solve the wrong problem.
  
  --
  Ezekiel 23:20
Until it's ubiquitous, it's still a no go... by Anonymous Coward · 2013-09-25 04:42 · Score: 0

I've tried to make an argument with the development studio where I work that we should be looking at C++11 for future projects, but the technical director and producer won't hear of it.
"It's not universally supported yet", being their biggest objection. Most significantly, MSVC's latest roadmap doesn't show full C++11 compliance before 2015, and the custom compilers used for some hardware platforms (particularly certain game consoles) don't even have a hint of C++11 support for current platforms on their horizon.
1. Re:Until it's ubiquitous, it's still a no go... by ledow · 2013-09-25 05:00 · Score: 2
  
  Surely those sort of decisions first need a case where - despite all efforts to the contrary - there's something that can't be done as easily any other way as it could if you moved to a new C++ standard.
  That's my biggest problem with most of these standards - quite what they add is hard to define, especially when the problems you point out are taken into account. Is there really anything in such a standard that couldn't be replicated by the programmers quite easily enough (or close enough), and would actually save more effort that it would take to create?
  Until you find a use case that is advantageous for the exact type of things you do everyday (and which you cannot replicate simply via alternate methods), it's probably best to stay where you are.
2. Re:Until it's ubiquitous, it's still a no go... by Anonymous Coward · 2013-09-25 05:02 · Score: 0
  
  too bad. the stl improvements are very nice. A lot of stuff I was doing already with 3rd party (boost, etc) or my own code was incorporated in. Normally, they go full retard with their "improvement" based on ivory tower thinking of what people should do (vector much?) This time, they looked at what people were actually doing with c++.
3. Re:Until it's ubiquitous, it's still a no go... by mark-t · 2013-09-25 05:06 · Score: 1
  
  I think the use case for its advantage would be development time by taking advantage of certain features that didn't exist in the language previously... but saving development time is meaningless if you can't actually develop for your intended target architecture.
  
  --
  File under 'M' for 'Manic ranting'
4. Re:Until it's ubiquitous, it's still a no go... by iampiti · 2013-09-25 07:44 · Score: 1
  
  Well, I'd say he's ok. IMO it's still to early to write C++11 code for any real products. It's not only the matter of the tools (that's the easy part) but the fact that most C++ aren't going to be familiar with those changes and new ways of doing things yet.
5. Re:Until it's ubiquitous, it's still a no go... by boristhespider · 2013-09-25 08:24 · Score: 1
  
  "it's still to early to write C++11 code for any real products"
  What you seem to mean is it's too early to write C++11 code for any real products if your development team aren't up to speed with it. That's a totally fair statement, but it's clearly not true that it's too early to write C++11 for real products -- we do. We're liable to swap to C++14 as soon as commercial compliant compilers become fully stable and settled (and, of course, that we can convince our IT support to license them, which may take a year or two).
  [Caveat: my personal experience with C++ was first with a Borland compiler probably not fully compliant with C++98, and then onto an MS compiler compliant with C++11, and a gap of 12 years. The language I came back to was significantly nicer - for my way of thinking - than the language I left. So I'm rather biased towards C++11 and even more so towards what I see coming up with C++1Y.]
6. Re:Until it's ubiquitous, it's still a no go... by neonsignal · 2013-09-25 11:59 · Score: 1
  
  I don't get the argument "It's not universally supported yet". It's a compiler, not an operating system. Unless perhaps you are trying to share a code base across extremely diverse systems. And even then, the backward compatibility is such that it just means you have to be careful about restricting certain features in the shared part of the code base. Most developers can cope with working on multiple dialects of a programming language, even, astonishingly, multiple languages! It doesn't make sense to not use language features when you can (unless you think those features are bad or buggy). And we have been working with compilers that don't have full compliance to any standard for a long time now!
  I can understand some caution in adopting a new compiler, but the C++11 features have been around in nascent form long before the standardization happened. It isn't like the committee doesn't take time to make decisions...
7. Re:Until it's ubiquitous, it's still a no go... by Anonymous Coward · 2013-09-25 15:35 · Score: 0
  
  Well, the whole point of using C++11 specifically would be to take advantage of its new features. Unfortunately, there are actually very few compilers out there that actually implement all of what I would consider to be the most useful new features like constexpr, user defined literals, C++11 atomics, and thread support.
BSD by Anonymous Coward · 2013-09-25 04:53 · Score: 0

Now that Clang/LLVM has got this finished, I'm wondering what a system would look like with:
* Linux as the kernel
* Clang/LLVM as the system C/C++ compiler
* Heirloom Toolchest as the basic userland toolchain
* Wayland as the underlying display system
* musl as the system C library
That would be Linux, but would contain almost no GNU code. Not that I have anything against GNU, but the Heirloom Toolchest, Clang, and musl are all more standards compliant, smaller, and often faster than their GNU counterparts. I wonder what a Linux distribution like that would look like. I'd use it.
(I hate how "GNU's Not Unix!" is really becoming more and more true. Unix was about minimalism, and sometimes GNU seems like it's about stuffing everything possible into every tool.)
So kind of like FreeBSD: less and less GNU code over time.
Bad analogy by Anonymous Coward · 2013-09-25 05:06 · Score: 0

Perhaps a much better one would be whether to call a Honda Civic a Am/Jap car because it has a Chevy engine...
1. Re:Bad analogy by Anonymous Coward · 2013-09-25 05:20 · Score: 0
  
  dafuq? Unless you're talking about the SBC swap you did in your garage, the engine in a Civic has never been from Chevy.
2. Re:Bad analogy by armanox · 2013-09-25 07:02 · Score: 1
  
  Not the engine, but we found parts in a friends Acura that had AC Delco (GM) part numbers on them.
  
  --
  I'm starting to think GNU is the problem with "GNU/Linux" these days.
3. Re:Bad analogy by tian2992 · 2013-09-25 10:10 · Score: 1
  
  Or maybe because it might as well be built in the USA http://www.hondainamerica.com/manufacturing
Everytime I read about C++1Y.. by InterBigs · 2013-09-25 05:14 · Score: 1

.. I want to start hacking around with it. But then I remember how much I love and I just don't care anymore.
1. Re:Everytime I read about C++1Y.. by InterBigs · 2013-09-25 05:14 · Score: 1
  
  ugh.. how much I love . Slashdot is not unlike C++.. who uses HTML in comments anyway?
2. Re:Everytime I read about C++1Y.. by Anonymous Coward · 2013-09-25 05:22 · Score: 1
  
  C++0xB made the language a bit more bearable for those times when you have no choice but to use it, but it certainly doesn't make me want to use C++ when I have any other alternative whatsoever.
3. Re:Everytime I read about C++1Y.. by stenvar · 2013-09-25 05:56 · Score: 0
  
  I hear you. Decade after decade, C++ is gradually fixing its enormous bulk of horrendous problems. It almost is a half decent language now. Almost.
4. Re:Everytime I read about C++1Y.. by Valdrax · 2013-09-25 06:00 · Score: 1
  
  Slashdot is not unlike C++.. who uses HTML in comments anyway?
  Personally, I tend to use the <quote> and <em> tags in over half the posts I make.
  It you don't like Slashdot's default behavior, switch your default posting method to "Extrans" instead of "Plain Old Text," and all your accidental HTML tags will get escaped out approrpriately. (Personally, I'd have used "[ ]" for a substitution indication rather than "< >", but YMMV.)
  
  --
  If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
5. Re:Everytime I read about C++1Y.. by K.+S.+Kyosuke · 2013-09-25 06:13 · Score: 2
  
  .. I want to start hacking around with it. But then I remember how much I love and I just don't care anymore.
  I gave up on C++ after I realized how much it confuses the problem of writing efficient software with the problem of giving you individually very efficient components that you're free to combine in ways that are either elegant, or efficient, but not both at once. I feel like it's 1970's all over again when I look at C++ code. Virtually *any* piece of C++ code, for that matter. There are better things one can do with one's life than endless psychological self-harm.
  
  --
  Ezekiel 23:20
6. Re:Everytime I read about C++1Y.. by Anonymous Coward · 2013-09-25 07:07 · Score: 1, Funny
  
  It's too bad your rotted your brain with Python and C# but C++ is the best language for non-trivial projects and will continue to be for the rest of our lifetimes.
7. Re:Everytime I read about C++1Y.. by Anonymous Coward · 2013-09-25 07:23 · Score: 0
  
  Maybe programming isn't for you then. Have you looked into janitorial work?
8. Re:Everytime I read about C++1Y.. by K.+S.+Kyosuke · 2013-09-25 08:04 · Score: 1
  
  I'd never touch Python and C# unless my life depended on it. And as far as "non-trivial projects" are concerned, I think you've misspelled "Common Lisp", at least in this and the following decade. What the more distant future holds I don't profess to know.
  
  --
  Ezekiel 23:20
9. Re:Everytime I read about C++1Y.. by Anonymous Coward · 2013-09-25 08:31 · Score: 0
  
  And you misspelled "Haskell". It must be international typo day.
10. Re:Everytime I read about C++1Y.. by HiThere · 2013-09-25 08:32 · Score: 1
  
  Lisp has it's points...but it's not that great. And many of the libraries that I want to use are a real pain to use from it. And the only decent development environment I've found is actually for Scheme (Racket), and while it provides, e.g., futures, it doesn't actually execute the code in parallel. (Yes, I know that's not actually a criticism of Common Lisp. For that stick with the libraries and the lack of a development environment.)
  P.S.: I once, long ago, bought a copy of Franz Lisp (my first common lisp). It was OK, but not great. And updating it would have cost me the other arm and leg. A usabe version isn't cheap. So I formed my opinions recently based on SBCL and CMUCL.
  Some people like Haskell, but I have a hard time thinking that way.
  Etc.
  Currently I've settled on D as the best compromise. It's missing a lot of libraries, but if there's a C interface, it's usually possible to link them to D.
  As for C/C++... my real problems with them are memory management and unicode. (With C++ I also despise the way one is required to use templates for everything. Generics are much preferable.)
  Now except for memory management and inflexibility (leading to verbosity), esp. in handling character strings, Ada is preferable in every way that I'm aware of to C++. C++ *used* to be a simpler language to learn, but that's not true any longer. The standard has expanded to the point where Ada is simple in comparison. (Ada *does* have usable memory management, but it's a lot more complex than a decent garbage collector. So while it's better than C/C++, it loses out in comparison to D, among others.)
  As for Java...I consider that it's way of handling unicode is broken. It works for many "characters", but not for the less common cases. And argument can be made for either utf-8 or utf-32, but utf-16 is a terrible compromise, even when done well, and Java is not an example of it being done well.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
11. Re:Everytime I read about C++1Y.. by ebno-10db · 2013-09-25 10:47 · Score: 1
  
  Currently I've settled on D as the best compromise.
  Have you used it successfully on serious projects? I'm intrigued by D, but have heard, even from fans, that it's still kind of buggy. Has that changed?
12. Re:Everytime I read about C++1Y.. by HiThere · 2013-09-25 12:34 · Score: 1
  
  Since I tend to find ALL environments, except things like Java, Python, and Ruby, a bit buggy, I can't really say. When did you hear that it was particularly buggy? (As it's under considerable development, the precise version is significant.)
  I tend to find more problems with my C++ code than with my D code. Of course, that's probably me, but ... And the C++ code is harder to debug. OTOH, if I need to use a library that crosses language boundaries, that does add another problematic element. It may depend on what you are doing. C/C++ gives me a lot of trouble when handling unicode strings. (For that, even Vala is better.)
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
13. Re:Everytime I read about C++1Y.. by Unknown+Lamer · 2013-09-25 16:56 · Score: 1
  
  Lisp has it's points...but it's not that great. And many of the libraries that I want to use are a real pain to use from it. And the only decent development environment I've found is actually for Scheme (Racket), and while it provides, e.g., futures, it doesn't actually execute the code in parallel. (Yes, I know that's not actually a criticism of Common Lisp. For that stick with the libraries and the lack of a development environment.) P.S.: I once, long ago, bought a copy of Franz Lisp (my first common lisp). It was OK, but not great. And updating it would have cost me the other arm and leg. A usabe version isn't cheap. So I formed my opinions recently based on SBCL and CMUCL.
  Emacs with SLIME nowadays is pretty nice. I think it's the best language environment I've ever used really, and what keeps me going back to CL despite knowing better (shouldn't have picked up SML...). The debugger is particularly excellent, and the inspector, xref support, etc. aren't too shabby either. As for libraries, there are plenty of excellent libraries for most every problem domain, but finding them over the half-finished ones and then managing your personal library... was unpleasant. Until Quicklisp appeared a couple of years ago. Now finding/installing/loading libraries is downright trivial: (ql:quickload #:SYSTEM) and you're done (Quicklisp will fetch the system and any dependencies if they are not available locally). It makes deploying programs muuuuuuch simpler (how much time I wasted keeping my development and deployment environments in sync, oi!). It also has the equivalent of apt-get upgrade, makes life easy when you're someone working on a system in quicklisp (you can use common-lisp-controller to make all Lisps on the machine prefer your development copy), and even manages your SLIME install (finally making it accessible to newcomers who have no idea what their .emacs is).
  CL has two things going for it: the standard provides a very complete language (and there's community consensus on extensions for threading, networking, etc.), and the Common Lisp Object System is the best OO language available. Of course, those functional programming folks say OO is sin...
  
  --
  
  HAL 7000, fewer features than the HAL 9000, but just as homicidal!
14. Re:Everytime I read about C++1Y.. by david_thornley · 2013-09-26 04:01 · Score: 1
  
  My memories of Lisp are from projects I was doing and didn't understand what I was doing at a time. It seemed so easy to change things as I went along. I've never seen as good a programming language when you don't know what you're doing.
  C and C++ are very different languages nowadays. It's also much easier to learn C++ than it used to be, since the STL stuff is much easier to use than the C-like stuff. Granted, it's harder to learn all the details, but you can look those up when you encounter them. In general, people who discuss C/C++ (except in the sense that one might write "Perl/COBOL") don't know what they're talking about, and in particular tend to write bad C++.
  Memory management hasn't been a problem for me since I started using smart pointers. Unicode works better with C++11.
  I don't understand what your problem with templates is. I'm not completely familiar with generics, but they don't appear to do quite as much. C++ template wizardry is best left to the experts, but simply using the templates is generally easy, and it doesn't look to me like doing what generics can do is any harder with templates. Could you explain?
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
15. Re:Everytime I read about C++1Y.. by HiThere · 2013-09-26 07:26 · Score: 1
  
  I haven't used EMACS for decades. When I did my fingers hurt from the contortions. They're LESS willing to accept multiple simultaneous keypresses now than they were. (It's not Lisp, but Bigloo Scheme tried to use SLIME, and I wasn't impressed. Of course, there were lots of problems, and things didn't load properly, but still...geany is much easier to use. It *does* have a Lisp mode, but I'm not sure what it does, and nobody has ever recommended it. As I don't use Lisp currently, I haven't investigated further.
  As for quicklisp...when the main page says paraphrase "to find out more go to twitter" I'm a bit dubious. I know it only claims to be beta, but as documentation goes that's pretty poor. (Presumably they have better documentation somewhere, but...the main web page says check twitter???)
  Yes, I have heard that CLOS is quite good. But it's hard to get far enough for that to become significant.
  P.S.: One of the things I dislike about Lisp, and a few other languages, is the lack of reasonable documentation tools. Doxygen is far from perfect, but it produces usable documentation. Epydoc is better, if you're using Python2. Ruby has a couple of acceptable tools. Smalltalk...well, Smalltalk is self contained. I'm not real thrilled with their documentation ideas, but they sort of work. Vala ... valadoc is promissing to develop into an acceptable documentation tool, but it's got a ways to go. Still, Vala doesn't claim to be out of beta. Java not only has javadoc, it can also use Doxygen. Lisp....well, if it's got a documentation tool, I don't know about it.
  P.P.S.: WRT functional programming: Languages need to support functional programming, because there are places where it's extremely useful. They also need to avoid only supporting functional programming, because one frequently NEEDS mutable state. My preferences lean heavily towards Object Oriented, but they sure don't begin and end there. Languages need to support multiple paradigms. One of the problems with Java is that external functions are a kludge. (Define them as static members of a class named, perhaps, Global.) In Java this isn't much of a problem, though, because one is already limited to one external class per file.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
16. Re:Everytime I read about C++1Y.. by HiThere · 2013-09-26 07:38 · Score: 1
  
  You are right, one can do much more with templates. In D templates are a turing complete language. I still don't like them. I tend to make decisions at run time, not at compile time, because they depend on the data that is read. This, of course, depends entirely on what you are doing. For some things, templates are great. But from my point of view the only useful part of them is captured by generics. (Don't think of Java generics, think of Ada. Java got it wrong because they kludged them into the language as a retrofit which couldn't break any working code. Possibly Haskell or OCaML got the concept better than Ada, but I don't know those languages well enough to comment. And I think they just called the idea "types", which ARE determined at compile time, but which are calculated by the compiler.)
  Smart pointers are nice in many ways. Most types of smart pointers, however, can't release nets of data. Garbage collection can, but determining that there are no external references. This has a time penalty, but, OTOH, it saves on space. So garbage collection vs. smart pointers is a time-space tradeoff. Which is best depends on what you are doing. OTOH, C/C++ are languages which are ill-suited to garbage collection, because you can't rely on data either being or not-being a pointer without a LOT of checking and calculation. Languages that are stricter on type conversions are better suited for garbage collectors.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
17. Re:Everytime I read about C++1Y.. by david_thornley · 2013-09-26 15:58 · Score: 1
  
  I'm not familiar with Ada generics. I've been looking at Java and C#. C++ templates seem to do what those generics do about as easily as the generics, while being capable of much more. They do have the disadvantage that you have to be careful of bloat.
  I don't see why smart pointers can't release nets of data. They can certainly cascade, since each delete triggers another destructor, which can delete more stuff. C and C++ can be garbage-collected. You have to use a conservative collector, which can retain more memory than necessary, but in practice that doesn't seem to be much of a problem. (Basically, search all the data space for things that could be pointers, since you can't figure out what the actual pointers are. That apparently doesn't retain much extra memory. It does rely on people keeping pointer values in a way that isn't undefined behavior.) The conceptual problem with garbage collection is that it only collects memory, while the RAII C++ approach collects everything that's no longer used.
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
18. Re:Everytime I read about C++1Y.. by HiThere · 2013-09-27 03:44 · Score: 1
  
  Smart pointers can't release nets of data because there are still references to each allocated cell. The references are mutually or cyclicaly referential, and there may be no external references, but there are still, possibly multiple, references. Garbage collection can notice that there are no external references to the data. The simplest example is a doubly linked list. Each cell in the list both references, and is referenced by, it's successor, if the head of the list is freed that doesn't free the list, it just makes it inaccessible.
  Yes, there are ways to handle this. But you need to use them, and each one is a potential memory leak. Which is likely not to be noticed in a small test case, but which will cause a problem when the program runs in production.
  Yes, C/C++ have garbage collectors. But because of the language design they need to work a lot harder than do garbage collectors of a language that properly separates pointers from other data. In practice it doesn't seem much of a problem, because people don't use them unless they REALLY need them. And your last sentence is a bit confusing. What in a running program isn't memory that COULD be collected? Are you talking about freeing memory from object databases (like ZODB) or what?
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
As long as you're on Wayland by smittyoneeach · 2013-09-25 05:58 · Score: 1

Stone Temple Pilots vs. Velvet Revolver is a far more rockin' analogy*.

*Any spelling errors contained in this gag are just so many flies in the vaseline.

--
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
1. Re:As long as you're on Wayland by Anonymous Coward · 2013-09-25 06:14 · Score: 0
  
  Did you get that analogy in the Vatican Gift Shop?
2. Re:As long as you're on Wayland by Anonymous Coward · 2013-09-25 10:18 · Score: 0
  
  Ouch!
A wrap-up of new features by jones_supa · 2013-09-25 07:36 · Score: 3, Informative

If you are interested, the GoingNative 2013 talks include a C++11/14 Sampler by Scott Meyers.
1. Re:A wrap-up of new features by loufoque · 2013-09-25 09:41 · Score: 1
  
  Alternatively, you could also attend conferences that are not over-sponsored by Microsoft and that despite having an all-star cast manage to be behind the times.
2. Re:A wrap-up of new features by sharklasers · 2013-09-25 17:56 · Score: 1
  
  I just knew the moment someone noticed the msdn part of the link, that they'd go off at Microsoft rather than the actual content presented in the talk.
libc++: part of LLVM or Clang? by unixisc · 2013-09-25 09:30 · Score: 1

Okay, I'm not a programmer, but shouldn't libc++ be a part of Clang - presumably C language, and not a part of a low level virtual machine?
B'cos if I understood it right, LLVM is the platform to which the code is compiled, while LLVM itself has to run on the bare metal. Or am I missing something here?
1. Re:libc++: part of LLVM or Clang? by bames53 · 2013-09-25 13:05 · Score: 1
  
  LLVM no longer stands for 'low level virtual machine'. It's simply random letters used as an umbrella name for a collection of different projects. The LLVM backend and libc++ are separate projects, but libc++ is also separate from clang.
This is a bit weak. by Anonymous Coward · 2013-09-25 09:50 · Score: 0

Where are static_if (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf) and modules (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf)?
*These* are the things that will really make C++ a better language and I can't wait to use them.
C++14 seems to be a very minor update. :(
1. Re:This is a bit weak. by bames53 · 2013-09-25 13:11 · Score: 1
  
  There's some controversy over whether the static_if proposal is really right, and modules is a major change which was never expected to get into C++14. As I understand it the current plan is for the committee to release modules as a technical specification separate from the overall C++ spec and then perhaps it will get rolled into C++17 or later.
Cat on the keyboard by xQx · 2013-09-25 10:59 · Score: 3, Funny

"LLVM's Libc++ Now Has C++1Y Standard Library Support"
Seriously, is that a real headline, or did your cat just walk across the keyboard?!
"free Linux-based OS with a multiwindow GUI" by tepples · 2013-09-25 11:30 · Score: 1

The "it" you are referring to doesn't need to be referred to at all.
It does when "free Linux-based OS with a multiwindow GUI" takes up the majority of a 50-character "Comment Subject" box. You need the "multiwindow GUI" part to distinguish the multitude of Linux distributions for desktop and laptop PCs from Android and from Linux distributions designed for servers.
How to refer to Linux distros that aren't Android by tepples · 2013-09-25 11:31 · Score: 1

If you must err on the side of brevity, GNU/Linux is best
I need brevity because there are plenty of Slashdot users who repeatedly point to Google Play Store as evidence that there are plenty of games and other commercial apps "on Linux". So is there a shorter term for Linux-based systems that aren't Android or embedded?
GNU/Linux is by far not the clunkiest term by tepples · 2013-09-25 11:34 · Score: 1

GNU/Linux is a term that should be universally rejected
It's still far less clunky than "Linux-with-a-GNU-userland" or "Linux-that-isn't-Android-or-embedded".
Name to list in app's system requirements by tepples · 2013-09-25 11:38 · Score: 1

Linux distributions have distinct names
Listing all Linux distributions in an application's "system requirements" would require excessive space. This means there's a need for a precise name for the set of Linux distributions that support Gtk+ and/or Qt userland as opposed to only the Android userland. Would Qt/Linux or Gtk+/Linux be more accurate?
Re:How to refer to Linux distros that aren't Andro by Zero__Kelvin · 2013-09-25 11:40 · Score: 1

Allow me to show you to handle such people.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Give me a better name by tepples · 2013-09-25 11:42 · Score: 1

Then what is the proper term for Debian, Fedora, Gentoo, and other desktop Linux distributions that resemble Debian, Fedora, and Gentoo more than Android?
1. Re:Give me a better name by Anonymous Coward · 2013-09-26 21:13 · Score: 0
  
  "desktop Linux?"
short term thinking is stupid by cas2000 · 2013-09-25 15:56 · Score: 4, Insightful

it really doesn't matter whether clang/llvm catches up to gcc or not in terms of speed or any other feature.
the crucial issue is what's strategically best for the long term interests of free software, and there is no way in hell that a compiler developed by the Lords of the Walled Garden at Apple is ever going to be a good thing for free software.
Apple's agenda is to sabotage copyleft and the GPL, because they want the benefits they can get from free code from tens of thousands of developers but without having to pay the entirely reasonable price of distributing and freely licensing the source along with any modified binaries.
The fact that Apple has been - and still is - smarter than Microsoft in their anti-free-software campaign just highlights how dangerous they are. Microsoft took the stupid head-on approach to attacking free software. Apple's method has been stealthy subversion and erosion of principles. smart, competent evil is far worse than stupid, incompetent evil.
1. Re:short term thinking is stupid by dkf · 2013-10-01 01:36 · Score: 1
  
  the crucial issue is what's strategically best for the long term interests of free software
  It's only crucial to some people (with yourself being obviously one of them). Others don't care nearly so much. If it's a BSD license, an attempt by someone to wall off the code would just result in everyone else forking from the last openly available version. Or it dying if nobody else actually cares, but in that case it doesn't matter. (If users care but no developers do, it's going to be hard to keep the thing alive whatever the license is.) Bear in mind that one of the few things that the BSD license prohibits is relicensing under different terms; for that, you always need the permission of the copyright holders, and there's no provision at all for retrospectively changing the license. But you knew that last part anyway, yes?
  BSD-style projects tend to prefer to keep the openness guaranteed through just social measures, instead of trying to enforce it via the license. I guess it might be thought of as a political difference, I suppose.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
Middle end by pne · 2013-09-25 23:05 · Score: 1

GCCs middle end is intentionally blurry
How can it be an end if it's in the middle?

--
Esli epei etot cumprenan, shris soa Sfaha.
LLVM Licensing by MobyDisk · 2013-09-26 06:20 · Score: 1

a compiler developed by the Lords of the Walled Garden at Apple is ever going to be a good thing for free software.
License: NCSA Open Source License
Product: ISO standards compliant
So what is the problem here?
1. Re:LLVM Licensing by cas2000 · 2013-09-27 17:14 · Score: 1
  
  > So what is the problem here?
  "Apple's agenda is to sabotage copyleft and the GPL"
2. Re:LLVM Licensing by MobyDisk · 2013-09-30 03:49 · Score: 1
  
  That is the definition of FUD.