I am a little confused by the result_of tests, which means either I don't understand the library, or there is a problem as most compilers are passing! The basic case: struct int_result_type { typedef int result_type; }; BOOST_STATIC_ASSERT (( is_same< result_of< int_result_type(float) >::type, int >::value )); If I understand correctly, this is asking what is the result_of a function taking a float and returning an int_result_type. Intuitively, and from my reading of the tr1 docs, that should be an int_result_type, not an int as asserted in the test. My reading of tr1 says that result_of< int_result_type > should return an int, but NOT functions that return an int_result_type. This support being in there to support unary_function, binary_function, and other function objects following that protocol. -- AlisdairM
AlisdairM wrote:
I am a little confused by the result_of tests, which means either I don't understand the library, or there is a problem as most compilers are passing!
The basic case:
struct int_result_type { typedef int result_type; };
BOOST_STATIC_ASSERT (( is_same< result_of< int_result_type(float) >::type, int >::value ));
If I understand correctly, this is asking what is the result_of a function taking a float and returning an int_result_type.
No, this is a common misunderstanding of result_of. result_of<F(X)> asks "what is the return type of f(x), where f is of type F and x is of type X?" So in the above case, it asks what the result would be if we were to create an instance of int_result_type and call it with 1.0f. The correct answer is, of course, "a compile time error", but the TR1 spec forces result_of to report 'int' for the usual reasons. :-)
Peter Dimov wrote:
AlisdairM wrote:
I am a little confused by the result_of tests, which means either I don't understand the library, or there is a problem as most compilers are passing!
The basic case:
struct int_result_type { typedef int result_type; };
BOOST_STATIC_ASSERT (( is_same< result_of< int_result_type(float) >::type, int >::value ));
If I understand correctly, this is asking what is the result_of a function taking a float and returning an int_result_type.
No, this is a common misunderstanding of result_of.
result_of<F(X)> asks "what is the return type of f(x), where f is of type F and x is of type X?"
So in the above case, it asks what the result would be if we were to create an instance of int_result_type and call it with 1.0f.
The correct answer is, of course, "a compile time error", but the TR1 spec forces result_of to report 'int' for the usual reasons. :-)
Wouldn't the result_of library be completely useless once typeof and other stuff like that be introduced into the language? Is the result_of library just a temporary patch accepted to tr1 only until C++0x? Or maybe I also didn't understand this library...
Yuval Ronen wrote:
Wouldn't the result_of library be completely useless once typeof and other stuff like that be introduced into the language? Is the result_of library just a temporary patch accepted to tr1 only until C++0x?
It would be nice if the answers to these questions turn out to be yes and yes, in no particular order. But there are indications that decltype won't be quite what it needs to be in order to render result_of useless. We'll have to wait and see.
On Jan 6, 2007, at 9:54 AM, Peter Dimov wrote:
Yuval Ronen wrote:
Wouldn't the result_of library be completely useless once typeof and other stuff like that be introduced into the language? Is the result_of library just a temporary patch accepted to tr1 only until C++0x?
It would be nice if the answers to these questions turn out to be yes and yes, in no particular order. But there are indications that decltype won't be quite what it needs to be in order to render result_of useless. We'll have to wait and see.
The intent was "yes" and "yes", but in the end we found that result_of still has some notational advantages over decltype in many cases. If anything is going to make result_of useless, it would be the introduction of the "Callable" concept, which gives the same information in addition to type-safety guarantees. If decltype does not end up with the right semantics to make implementing result_of trivial, I suspect it will be over the dead bodies of the majority of the Library Working Group. The reason we have "decltype" and not "typeof" is because someone wanted typeof to strip references... Cheers, Doug
participants (4)
-
AlisdairM -
Douglas Gregor -
Peter Dimov -
Yuval Ronen