John Maddock wrote:
Kirit Sælensminde wrote:
I think I have a misunderstanding of what the boost::function_traits is doing. From your explanation it seems that boost::function_traits is there to examine only function signatures where a function type is of the form R( A1, A2, etc. ),
Correct.
What is the reason for the restriction? It seems to make a number of common things unnecessarily verbose. For example, always having to wrap a some generic callable F with "typename boost::remove_pointer< F >::type". We don't need to do that if when we use the F. Higher order functions that take things like predicates allow us to just use the callable objects, why can't we do the same thing when we want to find out which types are involved? It makes a lot of idioms copied from functional programming much more verbose to do than it seems they really need to be. As I say, by adding the specialisations myself I can do all sorts of interesting things that are too difficult to do otherwise. For example, by adding specialisations for R(**)(...) I can use boost::function_traits with function pointers without needing to remember the remove_pointer. And by adding specialisations for boost::_bi::bind_t (which I probably have wrong, but stil) I can use boost::function_traits with the result of a boost::bind. What is wrong with that? Or do we need a new library Boost.CallableTraits to deal with it? K BTW boost::result_of does help with the verbiage if include the remove_pointer, but it still doesn't work with the result of a boost::bind.