You might also want to take a look at a multi-method implementation I have written several years ago for comparison. I would definitely love to see a (de facto or real) standard multi-method implementation. I never had the energy to pursue a full proposal to the C++ language committee. I wrote my implementation to prove that this could be done in a compiler and thus could be integrated into the language. It is definitely not optimal to do it in a library as everyone probably knows. Our implementation is not completely in the template coding style of boost, but as far as multi-methods go, it has been sufficiently capable for our needs; the main client has been a visualisation system I can describe in more detail if necessary. The front-end interface to developers uses a couple of macros, not templates. The macros are designed to give a feel of normal function definitions, but there are syntax limitations. Macros were chosen because a "nice" interface using templates simply didn't work across a variety of compilers -- both compile-time and run-time issues cropped up. Templates might work today fine; the macros do make fair use of templates internally already. There might still be issues with dynamically unloading templated code though. Back to the core matter. Features: 1) practically everything is at run-time, no compile-time limits or restrictions 2) no dispatch-time memory allocation (except if the method family has changed, see point 6) 3) any polymorphic class can be used as such for dispatching, no need to touch the participating classes in any way 4) handles real polymorphic calls, no need to have an exact match 5) supports arbitrary number of polymorphic arguments, including just one (the macro and template sugar on top is more restricted); arguments used in dispatch must be pointers to polymorphic types, and can't be null pointers at call time 6) supports arbitrary number of non-polymorphic arguments (actually limitation of the top syntax sugar layer, the dispatch engine only sees arguments used in dispatch); arguments not used in dispatch can be of any type, including scalars 7) handles dynamic changes the method family at run-time: it's ok to dynamically load and unload members of the family at any time 8) multi-methods can be globals or class (static) members; they are objects with operator() overload, not functions 9) the member functions of a multi-method can be either free-floating (global) functions or class (static) member functions, independent of whether the multi-method itself was a global or class-static (modulo privacy rules) 10) handles run-time ambiguity using the same rules as compile-time overload resolution, and refuses to make the call 11) supports large class hierarchies with several polymorphic arguments and several multimethods: doesn't compute the full dispatch matrix 12) decent dispatch time (= has never showed up in any profiling we've done) Currently it doesn't support invoking the next dispatch method, and it isn't thread-safe, but both are quite simple to add and will be done when it becomes an issue. In fact, making it thread-safe will naturally add support for next method dispatch. Documentation: http://seal.web.cern.ch/seal/snapshot/apiref/ classseal_1_1MultiMethod.html API and implementation: http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/SealBase/ MultiMethod.h http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/src/ MultiMethod.cpp Tests: http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/tests/ MultiMethod01.cpp http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/tests/ MultiMethod02.cpp http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/tests/ MultiMethod03.cpp Depends on: http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/SealBase/ XTypeInfo.h http://lcgapp.cern.ch/lxr/SEAL/source/Foundation/SealBase/src/ XTypeInfo.cpp Non-test examples of use: http://lxcms73.cern.ch/lxr/IGUANACMS/ident?i=MMM_DEFUN_FUNC Lassi -- If you think nobody cares, try missing a couple of payments.