Max Khesin <MKhesin@liquidnet.com> 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.