Re: [boost] Boost.Multimethod proposal

Subject: Re: [boost] Boost.Multimethod proposal
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-08-22 19:57:31

On Sat, Aug 22, 2009 at 5:37 PM, Nicholas Howe<nicholas.howe_at_[hidden]> wrote:
> On Sat, Aug 22, 2009 at 3:35 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>
>> How would this differ from the signals/slots library?
>>
>
> The difference is that when invoked, a multimethod selects a single best
> registered method implementation based on the dynamic types of its
> parameters, whereas signal calls all of its registered methods, which accept
> parameters of the same type.

Hmm, interesting thought.  What if all user-overloads where put in an
mpl map, and you registered all overloadable functions in a similar
way, but for the main function caller you could probably do something
like variant does for its visitors and recursive down for each of the
types based on the typeid (or more likely an mpl tag since it will be
stuffed into an mpl map anyway) using fusion to resolve the type at
runtime then using fusion::invoke or one of its kin, this would allow
it to be very efficient and would remove basically all the indirection
costs.  Could be made even more simple and efficient if the user was
willing to add a single macro into their class definition.  Hmm...