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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk