[boost] Re: overloads: request for discussion

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

Alexander Nasonov writes:
> Aleksey Gurtovoy wrote:
> > Can't it be something like
> >
> >     mpl::find_if<
> >         overload_set<1,5,has_intersection>
> >       , is_same<first_arg<_>, Circle&>
> >       >
> >
> > ?
>
> Well, I could use mpl find_if but it's not the best way (unless
> mpl::find_if is specialized).

[...]

> 3. Performance. When number of functions is high everything is
> important. For example, if all functions have same arity it decrease
> compilation time significantly. I have to pass a strategy to algorithms.
>
> Currently, this example looks like:
>
>      overloads::find_if<
>          overload_set<has_intersection, mpl::range_c<int,1,5> >
>        , is_same<first_arg<_>, Circle&>
>        >
>
> Close to your code but it's not mpl::find_if.

Hmm, what _is_ the strategy here? 'overload_set'?

>
> > > I used it till recently. But it's not quite an OverloadSet concept.
> > >
> > > 2. MPL-like sequence would be nice to have. Something similar to:
> > >
> > >     mpl::vector< bool(Circle&,    Circle&   )
> > >                , bool(Circle&,    Rectangle&)
> > >                , bool(Rectangle&, Circle&   )
> > >                , bool(Rectangle&, Rectangle&)
> > >                >
> > >
> > > or
> > >
> > >     mpl::set< bool(Circle&,    Circle&   )
> > >             , bool(Circle&,    Rectangle&)
> > >             , bool(Rectangle&, Circle&   )
> > >             , bool(Rectangle&, Rectangle&)
> > >             >
> > >
> > > Unfortunately, if typeof is not available, deref and some other
> > > operations work only in deduced context (that is, inside special
> > > function).
> >
> > I'm afraid I don't follow; the above seems perfectly viable to
> > me. Could you provide an example?
>
> It is viable. But function and metainformation (signature) are stored in
> different places. It's ok only if you have few functions. What if you
> have 400? Can mpl::vector or mpl::set contain 400 elements?

'mpl::set' definitely can. Structurally, it's not very different from an
"overload set".

> I'm afraid not. Some overloads library work even on higher numbers
> (up to 700 on my laptop).

Interesting. How do you generate these in the first place?

> 400 is not a random number. Imagine, you have 20 classes in Shape
> hierarchy. Intersestion of all of them requires 20x20=400
> has_intersection functions.
>
> BTW, I remember Dave mentioned that you generate FSM using mpl::vectorN,
> with N higher then default 50. How high is N?

~70, IIRC.

>
> > I think Fusion is already capable of building tuples based on the MPL
> > sequences.
>
> 1. It's different. In mpl case you use a sequence to generate tuple *type*.

I'd expect that you can generate a tuple type populated with some
corresponding values (?).

> In overloads case, it's both types and values. overload_set is more like
> mpl sequence of integral constants. You can pass it to for_each, for
> example.

IOW, it's a Fusion sequence?

>
> 2. The problem is that overload_set is not an MPL sequence.

I was assuming that we can make it such; the absence of standard 'typeof'
facility is really limiting, isn't it?

--
Aleksey Gurtovoy
MetaCommunications Engineering