-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 5 Feb 2011 10:26:20 -0800 Doug Gregor <doug.gregor@gmail.com> wrote:
Clang itself is just now getting some C++0x support. It has rvalue references, variadic templates, decltype, static_assert, and some other goodies. We think it's in decent shape, but obviously we need more testing coverage.
On Darwin. On Linux, clang C++0x support is a moot point because clang-linux uses the GNU stdlib. Also, according to the regression tests, clang + libc++ can't compile most of Boost.
- libc++ (Clang/LLVM's new C++0x standard library) works great with Clang's C++0x support.
libc++'s build system is very Mac centric. The last time I tried to use it on Linux, I was unsuccessful in doing so, because the build system relied on the existance of a darwin centric build tool. Has this situation changed? Is libc++ supported on Linux?
4.3, 4.4: fails, because the library was written at a time when rvalue references could bind to lvalues, which they now can't. so, Clang C++0x (correctly) rejects the code. This is just a casualty of shipping compilers and libraries based on an incomplete working paper.
4.3 and 4.4 are usable on Linux if C++0x support is disabled. At least, my version of clang is. Mainstream clang was, last time I checked.
4.5: fails, because the library uses generalized initializer lists, which Clang does not yet implement.
4.5 is semi-usable on Linux - there used to be a boost workaround for the <iomanip> header with 4.5. This was removed.
4.6: presumably fails because of both generalized initializer lists and constexpr, neither of which Clang does not yet implement.
Confirmed.
(I haven't tried Dinkumware or Apache; I suspect they'll need to be taught about Clang first).
Apache's stdlib is not functional. Part of the problem here is that GNU seems to make a policy of changing working parts of their C++(03/99) stdlib to use C++0x features that only G++ supports, without leaving the old, working C++03/C++99 code in place (the <iomanip> header change from 4.4 to 4.5 is an excellent example of this). Given that both Apple and Intel are targets of GNU's political attacks these days, and given that both Clang (an Apple supported compiler) and the intel compiler use the GNU stdlib on Linux, I suspect that GNU is intentionally trying to poison intel-linux and clang-linux. However, neither intel or the clang development team seem to be making efforts to move their compilers away from the GNU stdlib on Linux. If I had more time, I would invest time in making clang + linux + libc++ feasible, but I can't make that investment at this point in time. P.S. even if Apache's stdlib did work, Boost is not very Apache-stdlib friendly - - this is partially the cause of Sun/Pathscale/HP compiler incompatibilty with Boost. A notable example: the MSVC and GNU stdlib implicitly include <ios> when <iostream>/<istream>/<ostream> is included, pulling in the manipulators which the standard says <ios> must define. Apache's stdlib does not pull in <ios> in these situations, as the Apache standard library is much more conservative about implicit includes. Improving Apache library compatibilty would require Boost-wide changes, and I'm certainly not touching that subject after recent events. P.S.S. dgregor, don't get me wrong. I really like clang, and I think you guys are doing an excellent job. I have a TON of respect for you. As you probably know, I use clang as my primary compiler, and I invested a substantial amount of time compiling the Linux kernel with clang. I am saddened by the darwin-centric focus that I see in clang. I understand that a good portion of the clang development team is employeed by Apple, and I get that darwin is your focus. But things like the libc++ build system bother me. It would be a simple matter to make libc++ Linux friendly, and that would probably encourage Debian- and Redhat-maintainers of clang packages to ship clang on Linux with libc++ as the default standard library. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1NqSMACgkQ9cB/V3/s9Ey/KgCdEuu8Dh8WY1ol1WKeW0ArPNuw aEkAn1q2VIVsr4SKNu0PbHOXEUVteILB =DhD2 -----END PGP SIGNATURE-----