[result_of] vs decltype

Hi, What happens if result_of is not consistent with decltype? struct my_fun_t { template<class Sig> struct result; template<class This> struct result<This(int)> { typedef int type; // avoid dangling. }; template<class This> struct result<This(int const &)> { typedef int const & type; }; int const & operator()(int const &i) const { return i; } }; my_fun_t const my_fun = {}; int main() { boost::result_of<my_fun_t const(int)>::type x = my_fun(10); // ok in C++98. decltype(my_fun(10)) x_ = my_fun(10); // dangling in C++0x. } BTW, result_of implementation of my_fun_t is allowed in C++98? Regards, -- Shunsuke Sogame

On 11/26/07, shunsuke <pstade.mb@gmail.com> wrote:
Hi,
What happens if result_of is not consistent with decltype?
struct my_fun_t { template<class Sig> struct result;
template<class This> struct result<This(int)> { typedef int type; // avoid dangling. };
template<class This> struct result<This(int const &)> { typedef int const & type; };
int const & operator()(int const &i) const { return i; } };
my_fun_t const my_fun = {};
int main() { boost::result_of<my_fun_t const(int)>::type x = my_fun(10); // ok in C++98. decltype(my_fun(10)) x_ = my_fun(10); // dangling in C++0x. }
I do not think that a polymorphic function object is allowed to lie that way. The result metafunction must return the exact type which is returned by operator(). In fact even in TR1 an implementation is allowed to implement result_of using whatever compiler intrinsic (or trick) and only fall back to result when everything else fail. Of course in C++0x, result_of is required to be implemented with decltype (or equivalent). -- gpd

On Nov 26, 2007, at 6:35 AM, shunsuke wrote:
What happens if result_of is not consistent with decltype? [snip example]
TR1 (and the C++0x working paper) say that the program is ill-formed if result_of<...>::type isn't the same as the return type of the corresponding expression. - Doug
participants (3)
-
Doug Gregor
-
Giovanni Piero Deretta
-
shunsuke