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

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-08-18 15:45:57

From: "Jonathan Turkanis" <technews_at_[hidden]>
> <Arturo_Cuebas_at_[hidden]> 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;