[result_of] ambiguous instantiation for function pointers

Hi, CVS HEAD can't compile this under maybe any conforming compiler. (RC_1_34 is ok.) #include <boost/utility/result_of.hpp> int my_fun(int) { return 0; } template< class F > void test(F ) { typedef typename boost::result_of<F()>::type result_t; // shall be 'void'. } int main() { ::test(&my_fun); } Specializations are not enough? Regards, -- Shunsuke Sogame

shunsuke wrote:
Hi,
CVS HEAD can't compile this under maybe any conforming compiler. (RC_1_34 is ok.)
#include <boost/utility/result_of.hpp>
int my_fun(int) { return 0; }
template< class F > void test(F ) { typedef typename boost::result_of<F()>::type result_t; // shall be 'void'. }
int main() { ::test(&my_fun); }
Specializations are not enough?
I'm a bit confused. The type of F is int(*)(int). You're asking what the return type is if you call it with no parameters. But you can't do that! It takes an int. result_of<F(int)>::type compiles fine. I'm not sure this is a bug. Can you justify why you think this code should compile? -- Eric Niebler Boost Consulting www.boost-consulting.com

Eric Niebler wrote:
shunsuke wrote:
Hi,
CVS HEAD can't compile this under maybe any conforming compiler. (RC_1_34 is ok.)
#include <boost/utility/result_of.hpp>
int my_fun(int) { return 0; }
template< class F > void test(F ) { typedef typename boost::result_of<F()>::type result_t; // shall be 'void'. }
int main() { ::test(&my_fun); }
Specializations are not enough?
I'm a bit confused. The type of F is int(*)(int). You're asking what the return type is if you call it with no parameters. But you can't do that! It takes an int. result_of<F(int)>::type compiles fine. I'm not sure this is a bug. Can you justify why you think this code should compile?
AFAIK, nullary instantiations of 'result_of' must always succeed; for function forwarding. See the Rationale at http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html According to 20.5.4, I was slightly wrong. 'result_t' shall be 'int'? (I'm sure nobody cares, though.) Regards, -- Shunsuke Sogame

On Mon, 2007-03-05 at 13:12 +0900, shunsuke wrote:
Eric Niebler wrote:
shunsuke wrote:
Hi,
CVS HEAD can't compile this under maybe any conforming compiler. (RC_1_34 is ok.)
#include <boost/utility/result_of.hpp>
int my_fun(int) { return 0; }
template< class F > void test(F ) { typedef typename boost::result_of<F()>::type result_t; // shall be 'void'. }
int main() { ::test(&my_fun); }
Specializations are not enough?
I'm a bit confused. The type of F is int(*)(int). You're asking what the return type is if you call it with no parameters. But you can't do that! It takes an int. result_of<F(int)>::type compiles fine. I'm not sure this is a bug. Can you justify why you think this code should compile?
AFAIK, nullary instantiations of 'result_of' must always succeed; for function forwarding. See the Rationale at http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html
According to 20.5.4, I was slightly wrong. 'result_t' shall be 'int'? (I'm sure nobody cares, though.)
Yes, result_t should be 'int'. I've committed a fix to CVS; the patch I committed follows. Cheers, Doug Index: boost/utility/result_of.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/utility/result_of.hpp,v retrieving revision 1.9 diff -r1.9 result_of.hpp 17a18,19
#include <boost/mpl/if.hpp> #include <boost/mpl/bool.hpp> 57a60,65 template<typename FArgs> struct is_function_with_no_args : mpl::false_ {};
template<typename F> struct is_function_with_no_args<F(void)> : mpl::true_ {};
59,60c67 < struct result_of_impl<F, FArgs, false> < : F::template result<FArgs> ---
struct result_of_nested_result : F::template result<FArgs> 63,65c70,74 < template<typename F> < struct result_of_impl<F, F(void), false> < : result_of_void_impl<F>
template<typename F, typename FArgs> struct result_of_impl<F, FArgs, false> : mpl::if_<is_function_with_no_args<FArgs>, result_of_void_impl<F>, result_of_nested_result<F, FArgs> >::type

Douglas Gregor wrote:
According to 20.5.4, I was slightly wrong. 'result_t' shall be 'int'? (I'm sure nobody cares, though.)
Yes, result_t should be 'int'. I've committed a fix to CVS; the patch I committed follows.
That seems to work fine. Thanks a lot. Regards, -- Shunsuke Sogame
participants (3)
-
Douglas Gregor
-
Eric Niebler
-
shunsuke