Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming

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

Posted by Unknown Lamer 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.
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • !GNU/Linux (Score:5, Insightful)

    by Dimwit ( 36756 ) on Wednesday September 25, 2013 @11:31AM (#44949455)

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

    • 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

      • Re: (Score:3, Informative)

        by Anonymous Coward

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

        • I imagine most of the people invoking clang these days are using to do what OpenMP does.
        • Correction: I imagine most of the people invoking clang these days are using dispatch.h to do what OpenMP does.

        • 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... wh

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

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

            • (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 [gnu.org]

              C++ programs are fatter than pure C. So, now, GCC is fatter.

        • 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?

      • Re:GNU excitement (Score:5, Interesting)

        by Sectrish ( 949413 ) on Wednesday September 25, 2013 @12:22PM (#44950091) Homepage

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

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

      • Re: (Score:2)

        by DrXym ( 126579 )
        Slower. For a time. Chances are it would provide the motivation for someone to optimize it even more.

    • Re: (Score:2, Informative)

      by mark-t ( 151149 )

      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

      • 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

        • Re: (Score:3)

          by mark-t ( 151149 )

          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.

          • Would you rather it be called "GNU Userland/Linux"? In the same vein, would you be ok with Windows RT being called "Windows 8"?

            • Re: (Score:2)

              by dfghjk ( 711126 )

              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.

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

            by Raenex ( 947668 )

            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.

        • Re: (Score:2)

          by dfghjk ( 711126 )

          "GNU/Linux and Android are not compatible"

          There is no such thing as "GNU/Linux".

        • As of this writing, the reference toolchain for android is GCC 4.7.

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

    • Re:!GNU/Linux (Score:5, Interesting)

      by iluvcapra ( 782887 ) on Wednesday September 25, 2013 @12:00PM (#44949833)

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

      • Re: (Score:3)

        by lgw ( 121541 )

        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.

        • 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 para

          • Re: (Score:2)

            by lgw ( 121541 )

            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.

            • 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

              • Re: (Score:2)

                by lgw ( 121541 )

                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 t

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

      • GCCs middle end is intentionally blurry

        How can it be an end if it's in the middle?

    • I'm wondering what a system would look like with

      Sounds like your describing OSX

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

    • The basic set of UNIX command line tools is the only area on which a Linux operating system depends on GNU.

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

  • A wrap-up of new features (Score:4, Informative)

    by jones_supa ( 887896 ) on Wednesday September 25, 2013 @02:36PM (#44951843)
    If you are interested, the GoingNative 2013 talks [msdn.com] include a C++11/14 Sampler by Scott Meyers.

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

  • 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?

  • Cat on the keyboard (Score:4, Funny)

    by xQx ( 5744 ) on Wednesday September 25, 2013 @05:59PM (#44954297)

    "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?!

  • short term thinking is stupid (Score:5, Insightful)

    by cas2000 ( 148703 ) on Wednesday September 25, 2013 @10:56PM (#44956215)

    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.

    • 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?

Slashdot Top Deals

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Close