<Arturo_Cuebas@bpmicro.com> wrote in message:
Current pratice is to speficy the entire signature, including the (irrelevant) return type and the (redundant) class name. Arturo's suggestion gets rid of the return type and class name, but introduces the (irrelevant) arity.
When overloads differ only in the number of parameters and not the parameter types, arity becomes the only thing that's relevant. That's why I thought the ideal use would look like this when that's the case:
whatever_cast<1>(&P::f)
And like this when it's not:
whatever_cast<char>(&P::f)
I doubt that's possible though. :(
Right. You'd have to do something like this (switching to 'select_overload'): select_overload< mpl::int_<1> >(&P::f) which is pretty ugly. This formulation supports both flavors: select_overload< by_args<char, int> >(&P::f) select_overload< by_arity<3> >(&P::f) But the utility of select_overload as a space-saver is starting to dwindle.
static_cast form. IMO, the arity-specifying form is further away from that than the function-signature form. Consider that the return type can have a super-long name:
whatever_cast <long_name_templatized_type<unsigned long, unsigned char> (char)> (&P::f)
True, but in my personal experience this happen less often then long class names.
The essential information that needs to be supplied is just a typelist. [snip]
Is it possible to implement whatever_cast in such a way that it mimics what mpl::list does - in its acceptance of a variable number of template parameters - but produces a function?
Only if we had default template arguments for function templates. That's why Daniel mentioned boost::resolve<>::cast(&C::g); boost::resolve<int>::cast(&C::g); Jonathan