Boost logo

Boost :

Subject: Re: [boost] [result_of] fails with clan (C++11)
From: Eric Niebler (eric_at_[hidden])
Date: 2012-11-28 14:41:14


(Rearranging ...)

On 11/28/2012 11:32 AM, Oliver Kowalke wrote:
> Am 28.11.2012 19:45 schrieb "Eric Niebler" <eric_at_[hidden]>:
>
>> On 11/28/2012 6:14 AM, Mathias Gaunard wrote:
>>> On 28/11/12 08:42, Oliver Kowalke 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?
>>>>
>>>> it's called inside a templated function:
>>>> template< typename Fn >
>>>> void g(BOOST_RV_RV( Fn) fn){
>>>> BOOST_STATIC_ASSERT(...)
>>>> ....}
>>>
>>> remove the reference from Fn (at least in C++11).
>>> I don't know what the actual type of Fn is in C++03.
>>
>> Did my previous answer not fully address this issue? The function type
>> void(&)(X&) cannot be called with 0 arguments, so a decltype-based
>> result_of will have the behavior your observe. The old TR1-style
>> result_of will give you void. At present, decltype-based result_of is
>> only enabled for very recent clang builds. This explains the difference.
>
> would function_traits<Fn>::result_type work better?

You are asking result_of to compute the result of calling a unary
function that takes an X& with zero arguments. That's nonsensical. If
you intend to call it with an X&, then ask it what the result is when
called with an X&:

   boost::result_of< Fn(X&) >::type

This should correctly report void regardless of whether result_of uses
decltype or the TR1 result_of protocol.

HTH,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk