Boost.Test and Xcode 4.5 in C++11 Mode
Hi Everyone, I'm trying to build Boost.Test in trunk in C++11 mode with Apple's released Clang compiler with Xcode 4.5. Is this supported by Boost.Test? I keep getting this error somewhere deep in some preprocessor parts which is far outside my understanding. Here's my user-config.jam: using clang : : : <cxxflags>-Wall <cxxflags>-Wself-assign <cxxflags>-std=c++11 <cxxflags>-stdlib=libc++ <linkflags>-stdlib=libc++ ; I ask because I'm using Boost.Test as my current unit testing framework for cpp-netlib. I'm going to need to make a decision on whether I can continue using Boost.Test in C++11 mode as cpp-netlib is moving to C++11-only in its next version. Thanks in advance. -- Dean Michael Berris www.deanberris.com
On Fri, Nov 16, 2012 at 12:12 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Hi Everyone,
I'm trying to build Boost.Test in trunk in C++11 mode with Apple's released Clang compiler with Xcode 4.5. Is this supported by Boost.Test?
Filed: https://svn.boost.org/trac/boost/ticket/7697 -- Dean Michael Berris www.deanberris.com
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Hi Everyone,
Hi Dean,
I'm trying to build Boost.Test in trunk in C++11 mode with Apple's released Clang compiler with Xcode 4.5. Is this supported by Boost.Test?
Well is is intended to work ;)
I keep getting this error somewhere deep in some preprocessor parts which is far outside my understanding.
Would help if you can show it. I do not have access to this configuration BTW, clang seems to be working fine in general according to this: http://www.boost.org/development/tests/trunk/developer/test.html Gennadiy
On Fri, Nov 16, 2012 at 12:29 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
I'm trying to build Boost.Test in trunk in C++11 mode with Apple's released Clang compiler with Xcode 4.5. Is this supported by Boost.Test?
Well is is intended to work ;)
Thanks, that's good to know. :)
I keep getting this error somewhere deep in some preprocessor parts which is far outside my understanding.
Would help if you can show it. I do not have access to this configuration
BTW,
clang seems to be working fine in general according to this:
http://www.boost.org/development/tests/trunk/developer/test.html
Interesting. Is there a way to find out exactly what version of clang Sandia is using? If anything this may be a regression on clang I'm encountering. I have added more details to https://svn.boost.org/trac/boost/ticket/7697 which shows exactly what the error I encounter is. It seems to have something to do with decltype and boost::declval. Also, if it helps I'm on r81355. Thanks Gennadiy! -- Dean Michael Berris www.deanberris.com
On 15 November 2012 13:50, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Interesting. Is there a way to find out exactly what version of clang Sandia is using? If anything this may be a regression on clang I'm encountering.
You can find out by looking at the output of config_info in the config test results. Sandia are using 'Clang version 3.2 (trunk 168035)'. I tried building with Clang 3.1 in C++11 mode, and I got the same errors as you. As well as some other errors because I don't have std::enable_if - I think that BOOST_NO_CXX11_HDR_TYPE_TRAITS is the macro to check for in that case.
On 15 November 2012 14:54, Daniel James <dnljms@gmail.com> wrote:
I tried building with Clang 3.1 in C++11 mode, and I got the same errors as you.
I think it's a clang bug, here's a test case: template <typename T> struct foo {}; foo<decltype(1 > 0)> x; It thinks the '>' from '1 > 0' is an angle bracket, I guess it has been fixed on clang trunk. A workaround is just to double the round brackets. I've attached a patch that I used to get Boost.Test to compile. It's a bit messy though.
On Thu, Nov 15, 2012 at 7:24 PM, Daniel James <dnljms@gmail.com> wrote:
On 15 November 2012 14:54, Daniel James <dnljms@gmail.com> wrote:
I tried building with Clang 3.1 in C++11 mode, and I got the same errors as you.
I think it's a clang bug, here's a test case:
template <typename T> struct foo {}; foo<decltype(1 > 0)> x;
It thinks the '>' from '1 > 0' is an angle bracket, I guess it has been fixed on clang trunk. A workaround is just to double the round brackets. I've attached a patch that I used to get Boost.Test to compile. It's a bit messy though.
Note there is difference between decltype(x) and decltype((x)), so the change may alter the behavior. I didn't examine the code to confirm that though, just a heads up.
On 15 November 2012 15:32, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Thu, Nov 15, 2012 at 7:24 PM, Daniel James <dnljms@gmail.com> wrote:
On 15 November 2012 14:54, Daniel James <dnljms@gmail.com> wrote:
I tried building with Clang 3.1 in C++11 mode, and I got the same errors as you.
I think it's a clang bug, here's a test case:
template <typename T> struct foo {}; foo<decltype(1 > 0)> x;
It thinks the '>' from '1 > 0' is an angle bracket, I guess it has been fixed on clang trunk. A workaround is just to double the round brackets. I've attached a patch that I used to get Boost.Test to compile. It's a bit messy though.
Note there is difference between decltype(x) and decltype((x)), so the change may alter the behavior. I didn't examine the code to confirm that though, just a heads up.
Well, that's annoying. Just had a very quick read up on the issue, and I think it's okay. The expression is: typename boost::remove_reference< decltype((boost::declval<Lhs>() oper boost::declval<Rhs>() ))>::type result_type; 'oper' is a macro parameter, which is never '.' or '->' (obviously, given that it wouldn't work). So I don't think it counts as an id or member expression. 'oper' is '->*' in one case, but I don't think that's affected? If it is, the 'remove_reference' should help, maybe it would need to use 'remove_const' as well? Btw. please can someone with clang from subversion try the test case?
On Nov 15, 2012, at 11:32 AM, Daniel James <dnljms@gmail.com> wrote:
Btw. please can someone with clang from subversion try the test case?
Coming in late - where's the test case? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 15 November 2012 20:01, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 15, 2012, at 11:32 AM, Daniel James <dnljms@gmail.com> wrote:
Btw. please can someone with clang from subversion try the test case?
Coming in late - where's the test case?
Can you compile this is C++11 mode? template <typename T> struct foo {}; foo<decltype(1 > 0)> x;
On Nov 15, 2012, at 12:04 PM, Daniel James <dnljms@gmail.com> wrote:
On 15 November 2012 20:01, Marshall Clow <mclow.lists@gmail.com> wrote:
On Nov 15, 2012, at 11:32 AM, Daniel James <dnljms@gmail.com> wrote:
Btw. please can someone with clang from subversion try the test case?
Coming in late - where's the test case?
Can you compile this is C++11 mode?
template <typename T> struct foo {}; foo<decltype(1 > 0)> x;
Yes, I can. $ cat junk2.cpp template <typename T> struct foo {}; foo<decltype(1 > 0)> x; $ totclang11 junk2.cpp -c -Wall $ -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Daniel James <dnljms <at> gmail.com> writes:
On 15 November 2012 14:54, Daniel James <dnljms <at> gmail.com> wrote:
I tried building with Clang 3.1 in C++11 mode, and I got the same errors as you.
I think it's a clang bug, here's a test case:
template <typename T> struct foo {}; foo<decltype(1 > 0)> x;
It thinks the '>' from '1 > 0' is an angle bracket, I guess it has been fixed on clang trunk.
I checked in a fix, which just split above into two lines. The rest should work as is I believe. Please verify. Gennadiy
On 16 November 2012 00:52, Gennadiy Rozental <rogeeff@gmail.com> wrote:
I checked in a fix, which just split above into two lines. The rest should work as is I believe.
It isn't going to work for people using a C++11 compiler with an older standard library. This is quite common for people using clang, since libc++ is not easy to install on anything other than a Mac. I don't know how much of a problem it will be, but I did get bug reports when I didn't deal with that situation.
participants (5)
-
Andrey Semashev -
Daniel James -
Dean Michael Berris -
Gennadiy Rozental -
Marshall Clow