Re: [boost] Boost.Multimethod proposal

Subject: Re: [boost] Boost.Multimethod proposal
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-08-24 00:42:11

On Sun, Aug 23, 2009 at 9:45 PM, Nicholas Howe<nicholas.howe_at_[hidden]> wrote:
> On Sat, Aug 22, 2009 at 7:57 PM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
>> 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...
>
> I'm not certain, but it sounds like you might be suggesting resolving the
> mapping from dynamic parameter types to available methods at compile-time.
>  If so, I explained why I don't like that above.  If not, you'll have to go
> into more depth, as I don't follow.  My implementation caches the result of
> lookups, so I'm not particularly concerned by the cost of the resolution.
>
> I've looked over their documentation, but I'm not very familiar with variant
> and fusion.  I was aware that boost has tuple libraries, but I didn't use
> them because I didn't think I was doing anything very complicated and, of
> course, it's easier not to learn.  Then there's the excuse that keys have to
> cross library boundaries, so I want them to be part of the multimethod
> library, rather than a dependency, so they won't change unless they have to.

I might be able to whip up an example if you want, but what it would
do is populate a tree of type resolvers (this would actually allow for
unlimited type resolution, not just two) with plenty of use of
type_traits is_virtual_child and so forth all stuffed into templated
structs that resolve the lookups.  At compile time the tree is
created, at call-time into the multimethod it creates a lookup in the
tree that is specialized on the types passed into the multimethod
caller, and at runtime the specialized caller resolves through the
tree to compare the compile-time types at runtime, and if equal or if
proper children, then it is equal and calls the necessary method, it
will not fail since the base-most test could be tested at compile time
as well and if it is not a child of that then it would fail at
compile-time, but resolve to a specific function at runtime.  I have
been creating a lot of things like this recently for binding function
between scripting languages and C++, makes things so easy once you
figure out how to create it.  I love Boost.Fusion.  :)

> On Sat, Aug 22, 2009 at 11:01 PM, Jeffrey Bosboom <jbosboom_at_[hidden]> wrote:
>> There's a Stroustrup et al paper on the feasibility of adding multimethods
>> to C++ here: http://research.att.com/~bs/multimethods.pdf . I'm not sure
>> how relevant it is to the current proposal, but it contains information on
>> an experimental implementation that was faster than double dispatch.
>>
>
> I will read that.  I believe my proposal defines a simple interface for
> defining type relationships and registering methods, while leaving plenty of
> room for implementation changes.

Just for note, if you do read the PDF, he describes a method that
makes multi-methods have less cost then two virtual functions, and in
many cases it has equal cost to one virtual function program-wide, so
basically, much faster then your implementation, but his looks like it
might require a compiler back-end change.