[boost] Re: Re: Overload resolution & boost::bind

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-18 13:57:20

<Arturo_Cuebas_at_[hidden]> 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