|
Boost Users : |
Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-11-28 22:35:09
All,
Jeffrey Lee Hellrung, Jr. wrote:
>
> I had the same issue and posted it a few months ago. I wrote to the MS VS
>> forum that their std::result_of should work correctly with both old and new
>> formats; in particular use the declared result_type if it exists (which in
>> general lets the user override the deduced type, great for compatibility
>> issues).
>>
>>
>> Actually doing that robustly is a bit of a maze of metaprogramming. I
>> ended up making a local my_namespace::result_of that I just handles what I
>> needed, and only when I asked for it. That doesn't help the existing range
>> templates, but such a change could be put back into boost::result_of.
>>
>
> Maybe this is what you did, so I might not be suggesting something new,
> but... Perhaps boost::result_of could have an extra conditional logic
> branch added to it:
> - If F::result_type exists, return F::result_type;
> - Else:
> - If BOOST_NO_CXX11_DECLTYPE, return F::result< F ( Args... ) >
> - Else, if F::result<> exists, return F::result< F ( Args... ) >
> - Else return decltype( declval<F>() ( declval< Args >()... ) )
>
I like this -- it sounds like what John describes, but also using the
result struct. I'd suggest that structure if neither
BOOST_RESULT_OF_USE_DECLTYPE nor BOOST_RESULT_OF_USE_TR1 are defined (and
BOOST_NO_DECLTYPE_N3276 is defined).
Those who have been working on result_of the most lately haven't been on
this thread; I'll post this with a new subject to see what they say.
With or without a change to result_of, I believe there's value in allowing
the user to explicitly specify the result_type of a callable object passed
to transformed. Ticket #7748[1] contains a patch which permits that.
Thanks,
Nate
[1] https://svn.boost.org/trac/boost/ticket/7748
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net