Re: [Boost-users] Auto dispatch metaprogramming tricks

Subject: Re: [Boost-users] Auto dispatch metaprogramming tricks
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-05-21 10:37:08

(see my comments below)

----- Original Message ----- 
From: "Steven Watanabe" <watanabesj_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.user
To: <boost-users_at_[hidden]>
Sent: Friday, May 21, 2010 8:28 AM
Subject: Re: Auto dispatch metaprogramming tricks

> AMDG
>
> Alexander Lamaison wrote:
>> I would like to dispatch messages to a class based simply on the 
>> *presence*
>> of a message handler method.
>>
>> Currently, the classes maintain an MPL vector of the messages they handle
>> and must implement a on(message<MESSAGE_ID>) method for each one.  The
>> dispatcher uses this compile-time list to build the dispatching code. 
>> This
>> means the information is maintained twice and may fall out of sync (e.g.
>> adding the handler but forgetting to update the message vector.
>>
>> Are there any template metaprogramming tricks I can employ to dispatch 
>> the
>> message to a handler method if it exists and the default handler 
>> otherwise?
>> All this information is available at compile time.  The question is are
>> templates are powerful enough to make use of it?
>>
>
> Yes.  The code looks something like this:
>
> typedef char no;
> struct yes { char dummy[2]; };
>
> struct has_on_result {
>    has_on_result operator,(int);
> };
>
> no check_on_result(const has_on_result&);
> yes check_on_result(...);
>
> template<class T>
> struct has_on_impl : T {
>    using T::on;
>    has_on_result on(...);
> };
>
> template<class T, class M>
> struct has_on : boost::mpl::bool_<
>    sizeof(check_on_result(((has_on_impl<T>*)0)->on(*((M*)0)) , 0)) != 
> sizeof(no)
> > {};
>
> In Christ,
> Steven Watanabe

I think what Mr. Lamaison wants is:
give a message "handler" class like...

class Handler {
  void on(const M1&);
  void on(const M2&);
  void on(const M3&);
};

... is it possible to deduce ...

typedef mpl::vector<M1, M2, M3> HandledMessages;

... without knowing a priori the list of possible message messages

typedef mpl::vector<M1, M2, M3, ...> PosssibleMessages;

I think your example allows the user to determine if "Handler" has an "on" 
member function for a given a message type.
Though, to be honest, I'm not sure how your code works.  It looks 
fascinating!

Because, if you have to maintain PossibleMessages, then when a new message 
is added, the user would have to update PossibleMessages and and a method to 
"Handler", which is still two changes; i.e. no better.  Then again, 
filtering PossibleMessage using your "has_on" filter (using mpl::remove_if?) 
would be better if we assume that the list of PossibleMessages doesn't 
change very often, but users do regularly make Handlers that respond to 
various message subsets.

terry