On 11/27/2012 2:13 PM, Mathias Gaunard wrote:
On 27/11/12 22:21, Mathias Gaunard wrote:
On 27/11/12 21:56, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Nov 27, 2012 at 12:47 PM, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:
Hello, clang (c++11 support) fails on code like:
BOOST_STATIC_ASSERT(( is_same< void, typename result_of< Fn() >::type
::value));
with error:
no type named 'type' in 'boost::result_of<void (&())(X &)>' is_same< void, typename result_of< Fn() >::type
::value)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~**~~
Does Fn == void (&)(X&) or void (X&) ? I.e., is it a unary function type?
There might've been a recent change only for Clang to allow result_of to be better usable with SFINAE: result_of< F ( Args... ) > doesn't have a nested type typedef if F ( Args... ) is ill-formed (which appears to be the case here).
And the person who did that change didn't think of running the test?
My bad, I assumed this was a test from Boost, but this doesn't seem to be the case.
Right, this isn't a boost test case, and it's wrong in any case. This behavior is by design. The TR1 result_of protocol requires all nullary function signatures (like result_of<Fn()>::type) to be void, regardless of whether the function can actually be called with no arguments or not. The C++11 result_of (with decltype), result_of is supposed to get the right answer always. This was fully documented for the 1.52 release. There is a note in red on the boost.org homepage that takes you here: http://www.boost.org/users/news/a_special_note_for_boost_1_52_0_and_higher.h... And a link there takes you to the full discussion: http://www.boost.org/doc/libs/1_52_0/libs/utility/utility.htm#result_of Please see the section "Known differences between boost::result_of and TR1 result_of", which describes the difference for nullary functions and function objects. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com