Boost logo

Boost :

Subject: Re: [boost] [result_of] fails with clan (C++11)
From: Eric Niebler (eric_at_[hidden])
Date: 2012-11-27 18:03:11

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_at_[hidden]>wrote:
>>>> Hello,
>>>> clang (c++11 support) fails on code like:
>>>> 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 homepage that takes you here:

And a link there takes you to the full discussion:

Please see the section "Known differences between boost::result_of and
TR1 result_of", which describes the difference for nullary functions and
function objects.


Eric Niebler
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at