Re: [Boost-users] Auto dispatch metaprogramming tricks

Subject: Re: [Boost-users] Auto dispatch metaprogramming tricks
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2010-05-21 15:39:41

Firstly, thank you everyone for your replies.  There are amazing minds
here.

On Fri, 21 May 2010 09:37:08 -0500, Terry Golubiewski wrote:

> From: "Steven Watanabe" <watanabesj_at_[hidden]>

>> 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?
>>>
> 
> 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;

This is exactly what I'm trying to do.

> 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.

You have explained this much better than I did.  This is precisely the
situation I'm in.

So it seems that there are several pieces of code (thanks!) that give me a
compile-time predicate indicating whether the handler method is present
(I'm not sure if they differ in the details? The implementations certainly
look quite different; Steven and Terry's in particular).  As Terry points
out, there is a second half to the problem: how to dispatch arbitrary
messages?

To make it more concrete, I should explain that I'm dealing with Windows
window messages (e.g. WM_CREATE, WM_SETTEXT etc.) which are unsigned ints.
I dispatch these to handlers with the signature:

LRESULT on(message<WM_CREATE> m);
LRESULT on(message<WM_SETTEXT> m);
..and so on.

'message' is defined like this:

template<unsigned int Id> class message; // intentionally undefined

template<> class message<WM_CREATE> { ... }
template<> class message<WM_SETTEXT> { ... }

So there is in fact a list of 'PossibleMessages' available to the compiler.
It is every argument to a specialisation of class message<Id>.  Is there a
way I can harvest these to build the PossibleMessages list?

Thanks again.

Alex