Boost logo

Boost :

From: Max Khesin (MKhesin_at_[hidden])
Date: 2004-07-15 09:39:48


> Max Khesin <MKhesin_at_[hidden]> writes:
>
> > But not (from your phrasing) function members?
>
> I don't know about those; I haven't tried to find workarounds
> for that.
>
> FWIW, designs that depend on member detection are often flawed from a
> generic programming POV. You can get accidental conformance, and
> especially if there's no way to explicitly say what the member means
> (e.g. with a traits specialization), you'll be out-of-luck.

Well, this is my intent, just for the record, (perhaps there are other
techniques that apply):
I want a generic dispatch function that accepts some "Message", makes it
into a concrete class and dispatches it to the overloaded handler function:

// A, B, C, ... derived from some Base

template<class HandlerT>
void dispatchMsg(HandlerT& h, Msg m)
{
        if(m.getName()=="A")
        {
                h.onMsg(A(m));
        }else
        if(m.getName()=="B")
        {
                h.onMsg(B(m));
        }
// etc
}

the handler class has to implement overloaded handler functions for the the
classes it is interested in and (right now) a 'catch-all' handler for the
Base& (to insure that the thing compiles). Ideally I would like to eliminate
this requirement by detecting whether HandlerT has a onMsg(T&) and providing
a no-op for that (via another level of indirection), some thing like:

template<class HandlerT>
void dispatchMsg(HandlerT& h, Msg m)
{
        if(m.getName()=="A")
        {
                dispatcher<HAS_METH(h, void, onMsg, A&)>::dispatch(A(m));
        }else
        if(m.getName()=="B")
        {
                dispatcher<HAS_METH(h, void, onMsg, B&)>::dispatch(A(m));
        }
// etc
}
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk