Slashdot Mirror
LLVM's Libc++ Now Has C++1Y Standard Library Support
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.
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...
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.
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).
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.
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).
.. 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
If you are interested, the GoingNative 2013 talks include a C++11/14 Sampler by Scott Meyers.
"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?!
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.