From: "Jonathan Turkanis" <technews@kangaroologic.com>
<Arturo_Cuebas@bpmicro.com> wrote in message:
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)
Interesting.
But the utility of select_overload as a space-saver is starting to dwindle.
Maybe.
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.
What about when the return type is a typedef in the class with a long name or is unutterable? (The latter often happens with complicated metaprogramming expressions.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;