Subject: Re: [boost] [config][clang] Does <boost/config/compiler/clang.hpp> need updating?
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2011-02-05 13:26:20
On Wed, Feb 2, 2011 at 1:46 PM, Bryce Lelbach
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> I believe I've got the de-facto role of clang (linux) maintainer.
> Clang-linux C++0x support is very shaky (turning it on can break stdlib stuff)
> unless you have a clang compiled GNU stdlib or libc++. Until Redhat-based and
> Debian- based distros start shipping Clang with either 0.) clang-compiled GNU
> stdlib or 1.) clang friendly stdlib, we should probably only try to use C++0x
> support on Darwin. I need to investigate this more, though.
There are a number of inter-related issues here, so let me try to detangle them.
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.
Clang works with a few different C++ standard libraries, and that's
where C++0x gets interesting/messy:
- libc++ (Clang/LLVM's new C++0x standard library) works great with
Clang's C++0x support.
- libstdc++ (GCC's C++ standard library) has problems with Clang's
C++0x support, for different reasons in different versions:
4.2: "works", because it doesn't use any C++0x features, but of
course you don't have any library support
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.5: fails, because the library uses generalized initializer
lists, which Clang does not yet implement.
4.6: presumably fails because of both generalized initializer
lists and constexpr, neither of which Clang does not yet implement.
So, at this point, it only really makes sense to test Clang's C++0x
support either with libstdc++'s 4.2's non-C++0x library or with
libc++. (I haven't tried Dinkumware or Apache; I suspect they'll need
to be taught about Clang first).
> Hopefully there's a way to turn on C++0x support for clang by defining a macro,
> without making the stdlib believe that clang supports C++0x.
I don't think this is going to be practical. For libstdc++, we'll
probably have to write off 4.3 and 4.4 as great experiments with C++0x
that shouldn't be used for writing actual C++0x code, and we'll have
to wait until Clang's C++0x support catches up with GCC used of C++0x
in the library for 4.5/4.6.
Regarding Beman's original question about
<boost/config/compiler/clang.hpp>, I'll be happy to keep it up-to-date
with feature checks for Clang, since I'm also the maintainer of the
feature checks on the Clang side. I'm not a good candidate for
platform champion, though, because I don't watch Boost closely enough
to be helpful.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk