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 18:13:43

Another thing to consider is that using a single type-list with over 100 
message types will significantly (to me) slow compile time and may approach 
compiler limits.
You can avoid these limits by grouping messages into related groups or by 
using a dynamic dispatcher that registers callbacks at runtime 
initialization.

terry

----- Original Message ----- 
From: "Alexander Lamaison" <awl03_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.user
To: <boost-users_at_[hidden]>
Sent: Friday, May 21, 2010 2:39 PM
Subject: Re: Auto dispatch metaprogramming tricks

> 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