Clang is now feature complete for C++14 | Hacker News Reader

Clang is now feature complete for C++14

llvm.org

We shouldn't worry about C++11 / C++14 compiler support, which will eventually come, but rather standard libraries. It's a pain that libstdc++ still does not support some C++11 features[1] (no std::move on streams, for example).

They probably have good reasons, such as keeping the same ABI as long as possible, but it's sometimes very frustrating.

[1] http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s...

libcxx has not only implemented C++14 but they have also implemented all known defect reports at roughly the rate they get published!

http://libcxx.llvm.org/cxx1y_status.html

Unfortunately libc++ is fully supported on Mac OSX only, with ports on their way. I actually use libc++ on linux but there're still some things that need to be fixed. [1]

[1] http://libcxx.llvm.org/results.Linux.html

Those results are from over a year ago [1].

[1] http://llvm.org/viewvc/llvm-project?view=revision&revision=1...

Good point. I will run the tests myself to see the current status.

I still see the cuchar fail on Clang source 3.3, but maybe different on trunk.

Doesn't it run on FreeBSD?

David Chisnall likes to point out that it actually passes more of its test suite on FreeBSD than on OS X.

edit: thanks misframer

Chisnall

That's not entirely true. libc++ works on Linux too. In fact, Google's PNaCl has experimental libc++ support that's completely cross-platform.

And in windows too http://llvm.org/builds/

yeah right. It is beta-quality unfit for pre-packaging in distro's. ABI incompatible with libstdcxx and deliberately OS X only. (It works sure (i mean kinda) no one is actually a linux port developer or maintainer not yet)

Not just Mac OS X, it is in the FreeBSD base system by default, it is the replacement for the libstdc++. See FreeBSD 10 where the switch was made :-).

Good point, I believe clang + libstdc++ is a much more common combination than clang + libc++.
One thing I really don't like about libc++ is that it doesn't support anything from TR1 - makes it needlessly difficult to use in existing code bases.

I don't agree.

Would you mind to say why?

What I don't agree was this phrase.
*much more common combination*
Why? no clue, no reason. But Clang with libc++? There're reasons.
The primary Clang user groups are Apple and FreeBSD communities. a.k.a. anti-GCC groups. Both of them really want to avoid any GCC stuff and are officially deprecating all the GCC stuff. Having dependency to GCC stuff is nonsense on these platforms. If common developers are sane enough, they' won't use libstdc++.
And other group is the Linux development. But I don't think there're really many developers who are using Clang for production on Linux. There's no big push from the platform, and also no big benefits. But there're many shortcomings for using Clang. It's not installed by default, not supported by platform, not tested much.
If there're some people want to adapt Clang on Linux even now, they won't hesitate to use libc++. And the others will just stays in good old GCC with libstdc++.

>"and also no big benefits"
I think there are several benefits in using clang tools. You might find useful the Chandler Carruth's talk on Going Native on which he demoed some great tools that doesn't really have alternative on the gnu toolchain.
http://channel9.msdn.com/Events/GoingNative/2013/The-Care-an...

Clang certainly has its advantages (the faster compile times are very nice), but for a typical user that just wants to compile stuff, there's really nothing huge—and as always they need to balanced against the disadvantages. In general it's often a wash, and you may as well just use whatever comes with your system or whatever your friends use...
For me, the killer is typically optimization: e.g. for a CPU-intensive app I work on, gcc generates a binary that is twice as fast as what clang generates (this has been true for ages and across many compiler versions). I can live with slightly pokey compiles, but having my program take one week to execute instead of two is pretty compelling...

Many people prefer the error messages from clang

Would you mind submitting a bug report (with a reproduction case, if you're able) to the Clang team or mailing list? IIRC, they have an automated test suite for performance and regression testing; I'm sure they would greatly appreciate you taking the time to submit a test case where clang is producing egregiously slow binaries.

I could try, but although the difference seems localized to a fairly small number of functions, I haven't been able to precisely identify why it's so slow (there's no single inner loop etc that's slow), and shrinking it to something minimal would be hard...

> The primary Clang user groups are Apple and FreeBSD communities. a.k.a. anti-GCC groups.
I think you meant to say anti-GPLv3 groups and you also forgot to include Linux kernel devs.

The only sore thumb in libstdc++ is the regex library. It doesn't work and the headers exist. There are no warnings while compiling the code too. So, it'll appear like everything is dandy and it blows up at run time and usually developers don't think the fault lies in the library code...
This has led to a few hours down the drain...

I share your pain. Fortunately, gcc 4.9 will have <regex> support: http://gcc.gnu.org/gcc-4.9/changes.html

Oh! before doing C++14 gcc should please fix the std::list class; the size() method walks over the whole list in order to determine its size, outrageous.
template<typename _Tp, typename _Alloc = std::allocator<_Tp> > class list : protected _List_base<_Tp, _Alloc> { ... size_type size() const { return std::distance(begin(), end()); }

std::list is a doubly linked list, how else do you propose they do this? This is traditionally how list sizes are calculated.
(libc++ keeps a track of the size somewhere, but this in occurs a 4/8 byte overhead)

I think everyone will agree that using 4 bytes to store the size a much better idea than potentially enumerating millions of nodes just to count them, in the process completely blowing the cache and any optimizations the processors may do.
It's four goddamn bytes. Or eight if you really want more than 4 billion elements.

> It's four goddamn bytes. Or eight if you really want more than 4 billion elements.
As long as you don't have millions of lists with a few elements each -- you can't presume that they are only used one way :)

No, really, it's quite a safe assumption.
Hell, you probably lose that much to padding somewhere anyways.

According to http://www.cplusplus.com/reference/list/list/size/, list::size must be constant time in C++11.
That may make 'splice' slower. See http://home.roadrunner.com/~hinnant/On_list_size.html (I think that could be solved by having list iterators carry a field pointing to their container, but haven't given it much thought. Corrections welcome)

Having list iterators carry a field pointing to their container wouldn't help you determine the number of objects between two iterators when you splice, which is what you need in order to maintain the object count.
Storing an index in the iterator would not be a solution either. That would mean updating the index in all the existing iterators when you insert an object in the list.

Of course. Thanks.

It changes the ABI of std::list, which is a serious concern.

... and figuring out how to deal with that is the reason that libstdc++ is moving slowly on this.
libc++ has the luxury of assuming c++11.

Then you might be better off with a std::forward_list which is typically the size of a pointer.

Most STL implementations have always done this. This is one reason why it's better to use the empty() check for an empty container instead of size() == 0 for all container types.
Also, linked lists are notoriously crap for cache coherency / processor pre-fetching and branch prediction by processors anyway, given that there's no guarantee where each node will be allocated - the only way to do that is pull them off a slab allocator or something, in which case you might as well use a vector or deque anyway...

Sure, but blowing the cache just to count is nuts.

Not everybody will agree. One of the main advantages of std::list is splicing that can be done in O(1) if the size is not stored.

If the standard says it needs to be O(1) then you implement it that way and have a different list for fast splicing if needed.

Just make it the native size based on architecture. 4-byte int for 32-bit, 8-byte for 64-bit. It's impossible to store more than 4 billion elements on a 32-bit machine, you run out of memory first.

The standard in C++11 demands that size must be O(1). Also, there are some compilers that already are complaint in that regard.

That's new in C++11 though, isn't it? I'm pretty sure (i.e. I haven't checked the spec) that as far as C++03 the complexity was allowed to be linear. Honestly my sense of aesthetics agrees -- linked lists aren't supposed to have constant-time operations, there are better choices if that is a requirement. And if you want an augmented data structure you should cook your own: a list with extra tracking (i.e. ever node needs to have a pointer to the global thingy!) and insertion hooks isn't a "list" any more.

Yeah, they changed the wording from "should" to "must" be O(1) in C++11, which means that before, even when they encourage the implementer to do it constant, that was in fact optional.
I don't that tracking the size would be a big deal, if you think that doing that they wouldn't be a linked list any more, you could think it as a linked link wrapper.
In any case the complexity guarantees of all the other operations remain true so I don't think it is a big deal.

Make your own wrapper.

That's why i like C; you never bitch about such things, you just do your own list;
In C++ you are supposed to reuse standard abstractions; So you can - do your own std::list; (still have to copy iterators and everything into it;-) - do your own wrapper around std::list that exposes a weaker interface, - make your own list and everybody start to bitch that you are reinventing the wheel.

As you know in C++ you can do things the C++ way or the C way. That's why I like C++. If you want O(1) for size() of a collection you can use std::vector<> Of course, it doesn't suit every situation.

Patches are welcome. But it requires fsf copyright assignment.

GCC is behind in the race http://gcc.gnu.org/projects/cxx1y.html
Anyone recommends a good book, or any other dense/complete material, on C++11/C++14? I barely got C++11, never really practiced, and I could use a good material to dive deep into it.

For some videos I would recommend Going Native videos (http://channel9.msdn.com/Events/GoingNative/2013)
Also there is The tour of C++ (http://www.stroustrup.com/Tour.html) which offer a fresh start to the language.
But the one book I am waiting for is Effective C++ 11/14 which should coming up next year.

> But the one book I am waiting for is Effective C++ 11/14 which should coming up next year.
Likewise! And from your first link there is a sort of preview of Scott Meyers' upcoming book http://channel9.msdn.com/Events/GoingNative/2013/An-Effectiv...

Meyers' presentation slides, with notes, are available and excellent: http://www.artima.com/shop/overview_of_the_new_cpp. They include C++14. It isn't the deep dive, but it's a great overview.

In addition to the Going Native videos, Microsoft's STL wrangler, the conveniently named Stefan T. Lavavej, has a couple of terrific series on the STL itself[1] and the core C++ language[2]. The second course is newer, and thus covers more finalized C++11/14 features.
The more technical videos on Channel 9 are terrific stuff, and hooray for download links! Kudos to Microsoft.
[1] http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavave...
[2] http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavave...

True, Stefan is awesome... C9 is a great source for videos.
Also I forgot to mention C++ and Beyond (http://cppandbeyond.com/video-gallery/)

I'm told that political decisions regarding the architecture have greatly hampered gcc's progress, does anybody know if this is the case?
Either way, the better error messages in clang make it worth sticking to.

I highly recommend this: http://www.artima.com/shop/overview_of_the_new_cpp
By Scott Meyers

This is great :). On another note, I'm surprised that they're not using git or another dvcs.

They actually do[1]:
git clone http://llvm.org/git/llvm.git
[1] http://llvm.org/docs/GettingStarted.html#git-mirror

Oh ok, The main site under Dev Resources has a link to ViewVC.
Thanks for the clarification :)

That's actually a mirror though, all commits are through SVN.

Why does that matter? The best SCM is the one your team is familiar with.
(The second-best is git, of course. :)

It doesn't matter as long as your team is productive. I was just surprised, given the size of the project and all.

No template constraints yet?

concepts are not finalized yet, AFAIK

There's some proposal people are calling concepts-lite that is more or less a cleaner enable_if. There won't be a static_if in 14 from what I hear.

Destination C++17 :)

194 194 ? any reason except pure luck ?

Why, is there any reason to consider 194194 significant?
From 100100 to 194194 there are 194 of those kind of numbers (e.g 133133).
Even more if you count other symmetries as "significant", e.g 100001 or 123321

Every number is interesting http://en.wikipedia.org/wiki/Interesting_number_paradox

Or no number is interesting. The argument never proves the base case. ;)

If there was a number of interesting numbers, that number should include itself in the count, since we clearly have some interest in this topic. So if the number of interesting numbers is 0, then zero is an interesting number hence the number of interesting numbers is at least 1.

Alternately: if there are no interesting numbers, that fact is itself interesting. But that fact can be encoded as a number (see Gödel), and the number must be interesting if the fact is interesting. Thus there is at least one interesting number.

The fact being interesting doesn't mean its encoding is interesting. I might find a movie interesting but looking at the raw bytes of the MP4 file much less so ;)

Does such a thing actually exist outside of the encoding used to represent it?
Uh oh, I think we may have run into... PHILOSOPHY!
http://xkcd.com/903/

Surely there are only 95 repeated pairs of three digits between 100100 and 194194? And another 95 symmetric numbers. With a leading zero you have 195 each way.

In hex it's 0x2F692, so no longer interesting

It's SVN and revisions are sequential, so it is only a matter of time, not luck.

It's a sign that you're over-due for switching to Mercurial or Git for your version control.
Subversion is the equivalent of using paper tape to store your source code. It's centralized, bloody slow, and missing a number of features taken for granted in a system like Git.

Reply on news.ycombinator.com