Re: [boost] Runtime Dynamic Dispatch Library (0.2)

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-09-30 14:15:47

On 9/30/07, Marco Costalba <mcostalba_at_[hidden]> wrote:
> On 9/30/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> > >
> > > is not clear to me when and where this invokers are called given that
> > > dispatcher::operator[] returns a function object reference. Or perhaps
> > > I misread.
> > >
> >
> > Can you refer to which page in the documentation you see that?
> >
>
> If you mean the above example is in:
> dispatcher-0.2/libs/dispatcher/doc/index.html
>

Ah, this documentation is I think a bit dated -- and is one of the
earlier attempts at defining what the dispatcher is supposed to look
like. Please refer to the generated documentation in
dispatcher-0.2/libs/dispatcher/doc/html/index.html -- at least it's
prettier, and is more hierarchically coherent (or so i think. ;) ).

> >
> > The immediate "top of my head" implementation would be to do a linear
> > inheritance of the different Functor objects that support different
> > signatures to represent a multi-signature Functor wrappers.
>
> --------- cut ---------------
>
> >
> > void foo(double d) ;
> > void bar(string s) ;
> > void fizz(int i) ;
> >
> > multi_index_dispatcher d;
> > d[0] = foo; // valid, will register the void(double)
> > d[0] = bar; // valid, will register the void(string)
> > d[0] = fizz; // valid, will register the void(int)
>
>
> Also Dispatcher::operator=() should be 'stacked' in some way though...but how?
>

Remember that operator=() can be implemented as part of the class --
and it can be overloaded much like the other operators. That means:

Functor<void(int)> has: Functor<void(int)> &
operator=(boost::function<void(int)> const & function) {
  this->_wrapped_function = function;
  return *this;
};

Function<void(double)> has: Functor<void(double)> &
operator=(boost::function<void(double)> const & function) {
  this->_wrapped_function = function;
  return *this;
};

And since it's linear inheritance, the derived type (or at least the
one in the end of the inheritance hierarchy) will inherit all these
overloads to operator=() which will enable the compiler to choose at
compile time which overload it's going to use depending on what's on
the right hand side of the operator=().

>
> > d[0](1.0); // valid, will call the void(double)
> > d[0](1); // valid, will call the void(int)
> > d[0]("1"); // valid, will call the void(string)
> >
> > This might also be achievable with an encapsulated Fusion map instead
> > of linear inheritance, but I'm not entirely sure about being able to
> > generate the appropriate type-safe operator() overloads in that
> > manner.
> >
>
> Perhaps if the key of the map is the function signature could be
> possible first find a match with the supplied arguments and then call
> the operator(), should be safe in that case. A (big) downside is that
> you forget implicit conversions this way.
>

This is one problem with the Fusion map approach, but something I
perceive as really a non-issue -- because after all, the goal of the
library is to provide a type-safe way of implementing a dispatcher.

However, I find that your requirement for implicit type conversion is
something I particularly don't find very compelling since I'd rather
have at compile time (or statically) know that I'm performing a
conversion -- with static_cast<> or copy construction -- instead of
the compiler doing it for me. I think allowing for implicit
conversions is very dangerous and contrary to the notion of
type-safety -- but don't let that stop you from implementing it and
making it a design goal. It's just how I see it, which you can safely
ignore. :)

>
> >
> > Thank you for the interest, and I definitely hope the above
> > explanation helps. :)
> >
>
> Helped a lot.
>

I'm glad it helped. :)

> Thanks
> Marco

You're welcome. :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis_at_[hidden]]
[[phone]]
[[phone]]