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 19:30:01

On Fri, 21 May 2010 17:50:20 -0400, John Dlugosz wrote:

>> 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?
> 
> Derive message<T> from a "tag" base class.  Then you don't build a list,
> but you have a predicate to test "is this type in my set?" by using
> is_base_of, that's perfectly useful for enable_if. 

It's building this set that's the problem, not checking if an item is in
it.  I need a list of all messages IDs (UINTs) that have a message<BLAH>
specialisation.

> On the other hand, you could use a signature that matches the use of the
> template: 
> 
> template<typename Msg> LRESULT on (message<T> m); 
> 
> will only match this templatized member function if it is indeed a
> specialization of message. 

Yes, this is how my handlers work (except the on() method is not itself a
template - does that affect it?).

> BTW, I take a different approach to the problem in general.  Rather than
> a zillion individual handlers, I use small "pods" of related messages. 

I'm building a native Windows Forms library so the public interface won't
actually have any messages at all; only events.  The stuff I'm doing now,
however, is the intermediate layer so I still have to deal with messages.

> For example, handling the mouse messages is a class that handles just a
> few mouse-related messages, and if you deal with one you probably deal
> with all.  The pods are kept in a linked list, which is searched for
> suitable handlers.  

How do you match the incoming message ID to the pods?

> This allows run-time "modes" by updating that list
> or enabling specific entries that lie dormant. By having different
> specially declared functions for each Windows message (yet, not a
> million virtual functions in one class!) each can have a proper
> signature that wraps its real use, rather than dealing with the raw
> format. 

I'm afraid I don't understand this bit.  What do you mean by specially
declared functions?

Thanks.

Alex