[boost] Re: overloads: request for discussion

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-01-23 23:23:42

Aleksey Gurtovoy writes:
> Alexander Nasonov writes:
> > Good news, I can use mpl:find_if even though typeof isn't available!
> >
> > This is how I do it:
> >
> >   1. define overload_set_iter class template that takes an overload set
> >      and an iterator for current position.
> >      (If it was ever possible, deref could return a signature of an overload
> >      the iterator refers to).
>
> What if you define a "signature" as an (overload set, index) pair, declare
> it as a standard way to pass things around (within your library, that is), and
> make 'overload_set_iter' return that on dereference? Any reason why the
> approach you outline below is preferable?

Oh, I see it now: specializing 'iter_apply1' allows for intuitively
obvious

    find_if< overloads, is_same<bool(int),_1> >

while my suggestion would require something like

    find_if<
          overloads
        , overload_match< _1, is_same<bool(int),_1> >
        >

That's indeed quite appealing. However, specializing 'iter_apply1' this way
assumes that it's always invoked on a predicate metafunction, which,
at least theoretically, does not hold. On the other hand, with 'typeof',
dereferencing 'overload_set_iter' would simply return a corresponding
function type and things would "just work" without any special effort on
our side, and in that light 'iter_apply1' specialization for the compilers
that need it is simply an implementation detail which I'm willing to close
my eyes to ;). It's going to be interesting to see how many MPL algorithms
can be made to work with overload sequences using this approach.

--
Aleksey Gurtovoy
MetaCommunications Engineering