I uploaded to boost vault a new version of my implementation of Boost.Overload: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=overload-mrcec-20071011.zip&directory=& Boost.Overload is a multi-signature overloaded Boost.Function wrapper, which wraps multiple Boost.Function objects of different signatures as a single multi-signature overloaded function wrapper. For a brief introduction you can read some preliminary documentation that was kindly written down by Dean Michael Berris: http://tinyurl.com/3xtbyl For the post of the previous version you should look at: http://lists.boost.org/Archives/boost/2007/10/128289.php What's new: at present I worked on the second implementation only, and what follow is about such implementation; the source code has gone through refactoring and modularization; any dipendency by boost::is_base_of has been removed; the default assignment behaviour for overloaded and polymorfic function objects is changed: now for any signature S, included in an instantiation "o" of the template class overload, that matches at least one of the signatures of the passed function object "f", we have that the object of type boost::function<S> embedded in an instance of type "o" utilizes "f" as its target; example: struct foo { template< typename T > T operator()(T x) { return x + 1; } }; char foo2(std::string ) { return 'x'; } typedef int sig1_t (int ); typedef char sig2_t (std::string ); typedef double sig3_t (double ); int main() { boost::overload<sig1_t,sig2_t,sig3_t> ov; foo f; ov.set(f); // this is equivalent to // ov.set<sig1_t>(f); // ov.set<sig3_t>(f); ov.set(&foo2); // this is equivalent to // ov.set<sig2_t>(&foo2) return 0; } I think that this behaviour is the most natural and the one that is expected by the user. If we want to set a polymorfic function object as the target for only one specific signature we can always rely on set<signature_type>(f) or set<index>(f). I tested the source code with gcc 4.1.2 under Linux. Boost community helpful suggestions and critiques about interface, implementation and documentation are welcome. Above all I'd appreciate anyone pointing out bugs, compatibility issues, and library use cases. Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/